question: Allow all users and inject headers for authenticated users at the same time

[infogulch]

I want to manage authorization inside my application, which responds differently to public and authenticated users based on their logged-in status.

I tried bypass uri / but that just aborts all attempts to authenticate and fails to process the header injections.

authorization policy maybe_authenticated {
	set auth url http://127.0.0.1:8081/
	allow roles authp/admin authp/user
	bypass uri prefix /
	# inject headers with claims
	enable strip token
	inject header "Remote-Name" from "name"
	inject header "Remote-User" from "sub"
	inject header "Remote-Email" from "email"
	inject header "Remote-Groups" from "roles"
}

How can I allow all requests through, while processing and injecting headers for requests that are already authenticated?

Related: #278

[infogulch]

Does caddy-security/go-authcrunch support anonymous users and authenticated users at the same time? Think of a public site like HN, where the page shows to public and authenticated users, but authenticated users have additional abilities like voting and replying.

[greenpau]

@infogulch , this is better supported by caddy’s route matcher. Create a matcher that meets a specific condition that does not require authorization. You can use bypass uri to exclude a particular path prefix, but it needs to be something like /public/

[infogulch]

Ok, but I still want caddy-security to decode the jwt and add headers like I have it configured to do when the user is logged in. Can it do that?

[greenpau]

@infogulch , youz want to grant “guest” user access without authentication? What would you decode if a user did not authenticate?

[infogulch]

Yes.

My preference would be to omit headers that require a decoded token value entirely and add a different header like Remote-Guest: 1.

Could also set them to empty string or some other chosen default.

[infogulch]

What do you think, is this a reasonable thing to do?

[greenpau]

@infogulch , there is a pending feature request for this.

in short, if a token not found, then a user gets “anonymous” token by way of multiple redirects, but I never implemented it.