authentication support: work has begun!

[Peter Wu]

On Wednesday 15 January 2014 14:42:12 Jason A. Donenfeld wrote:
> > An important consideration is caching. Adding the Set-Cookie header
> > disables
> > caching for nginx at least, but other authenticated requests can still be
> > cached.
> 
> Not completely though. I've taken careful precaution to ensure that caching
> from the cgit end stays in tact. If the cookie is authenticated, then cgit
> is able to serve up the cached pages from its own cache. If the cookie is
> unauthenticated, then, yes, it displays an uncached version of the "please
> authenticate" page.
> 
> I did not check the ramification this has on nginx's handling of HTTP
> caching of resources, however. Can you elaborate on this, if it's a
> problem, and how to mitigate it?

Consider the use of fastcgi_cache as shown in this config:
http://lists.zx2c4.com/pipermail/cgit/2013-April/001307.html

The current login page is cachable, you should add "Cache-Control: private" to 
prevent that. Otherwise, with the nginx fastcgi cache enabled, you will still
see the login page. Perhaps a redirect to /login?url=%2Fglouglou%2Flog is more 
obvious? (302)

A related issue exists when
(1) an authenticated user requests the resource. nginx caches it.
(2) an unauthenticated user requests the resource. nginx cache returns the 
supposedly password-protected resource.

Again, use of the Cache-Control header would help here, but then no protected 
resource will be cached by nginx (bug/feature).

> The HMAC mention doesn't have to do with cleartext vs non-cleartext. It's
> for this reason -- I'm not going to be relying in an "auth=1" cookie for
> authentication passing. This is trivially spoofable. Instead, there's going
> to be something like "${username}|${expiration-unix-time}|${salt}|${hmac}",
> so that such state is stored in the cookie itself, but then validated
> server side using a secret.

Yes, I understood that auth=1 is a temporary hack for demonstration purposes, 
your use of a HMAC looks safe. :)

Aside from storing passwords in plaintext, I see no other obvious issues.

Thanks,
Peter