couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Bisbee <sbis...@computervip.com>
Subject Re: authentication cleanup
Date Sun, 03 Jan 2010 23:17:26 GMT
On Sun, Jan 03, 2010 at 12:55:29PM -0800, Chris Anderson wrote:
> On Sun, Jan 3, 2010 at 11:50 AM, Sam Bisbee <sbisbee@computervip.com> wrote:
> > On Sun, Jan 03, 2010 at 08:31:19AM -0800, Chris Anderson wrote:
> >> On Sun, Jan 3, 2010 at 5:28 AM, Benoit Chesneau <bchesneau@gmail.com>
wrote:
> >> > Just tested it, admin creation seem to work during the test I've done
> >> > at least admin user is created, for the rest I don't know, am not sure
> >> > yet what could be done with the changes, I need to have a closer look
> >> > in the code for it. There is a bug you mentioned in another mail with
> >> > tests, if we are loggged out, test fails and logically tests requiring
> >> > auth failed, to follow one of your proposal, I think we should add a
> >> > warning on top of tests saying that an admin user exists and tests
> >> > will fail; something like it.
> >>
> >> I was thinking we could even add some code which loads the admin
> >> config into a cookie, and then clears admins. When the tests are done
> >> it can re-configure the admins.
> >
> > This scares me: if the browser/client crashes while the tests are running, then
> > you've likely lost your admin config. Also, you're leaving yourself unprotected
> > for the length of the tests if it's a live system (doesn't even have to be
> > production, just on the 'net).
> >
[snip]
> Current trunk has failing tests when Couch isn't in admin party mode.
> So putting the warning and the option to temporarily remove admins
> before running tests is a step in the right direction. I think cookie storage
> for admin config is robust enough for the cases where someone would think of
> using it... it's essentially a convenience.

Agreed that it's a good band aid. However, is there some way we could store it
server side? I'm concerned about the security implications. Sniffing the config
from the wire (assuming no HTTPS), browser, or OS file system aside, there is
the possibility of injection of bad accounts. Better put, it's the pillar of
security to never trust what the client sends you.

Maybe write it to the OS's temp file space? That way it's safe and if something
crashes you can still easily recover the config. You could even automate the
recovery if you wanted to, which you couldn't reliably do if it came from the
client. 

Cheers,

-- 
Sam Bisbee

Mime
View raw message