From mboxrd@z Thu Jan 1 00:00:00 1970 From: lekensteyn at gmail.com (Peter Wu) Date: Wed, 15 Jan 2014 19:17:51 +0100 Subject: authentication support: work has begun! In-Reply-To: References: <14648906.FqII7cU9cN@al> Message-ID: <4500221.0uF48Q1BnU@al> 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