Example is very misleading

[ieure]

It looks like the default behavior in authenticate* is allow-anon? true. This makes the example extremely misleading, since the supposedly secured app allows any request by default, and you must dig into the source to discover why this is so.

Honestly I don't know why this is an option vs. not using friend for things that should have anonymous access, but this is a rotten thing to omit in an example.

[cemerick]

Perhaps the term "secured app" as used in the example is misleading, but the default value for (and existence of) allow-anon? is what I found most intuitive of the potential options: establishing a context within which users may carry authentication information, some sub-context(s) of which may require authentication, and others that may further require particular authorization. This maps well to my experience of building various types of web sites and services, where there are often anon-safe resources conceptually comingled with resources that require any role (i.e. any authentication will do) or some specific roles / conditions (i.e. particular authorization conditions).

Certainly, better documentation is warranted.

[ieure]

Your response conflates any authentication with no authentication; the latter behavior is friend's default. This seems like an extremely dangerous thing for something intended to control access to resources. To me, it violates the principle of least surprise that the default behavior of an authentication system is to allow unauthenticated access. The code says authenticate, but doesn't do what it says it should do. That's a problem.

The fact that there is no mention of this in any of the docs is also incredible. The only way you know that this behavior exists at all is by diving into the source.

I take your point, and I think that it's a problem due to tight coupling of two different concepts in friend: the authentication state of the current request vs. the permission to access the requested resource. Certainly for a webapp, you nearly always want to know what the state is, so you can show the correct login / logout controls. But the fact that there isn't an explicit distinction is an issue. If you established a context with (friend/context…), then controlled access with (friend/restrict-to :authenticated) (or some predicate fn), I think that would accurately reflect what is actually going on inside of friend.