a digest authentication module

[Alexandr Gomoliako]

On Sat, Nov 5, 2011 at 9:34 PM, Samizdat Drafting Co.
<drafting at samizdat.cc> wrote:
> i've recently been working on a digest auth module for nginx and have
> some functional (but untested) code posted here:
> https://github.com/samizdatco/ngx-http-auth-digest
>
> for the most part it seems to obey the RFC and is compatible with the
> browsers i've tried, so i'm confident that with a bit more work it
> could actually be usable in practice.
>
> however i've run into a few roadblocks along the way, mostly relating
> to saving state across requests and i wondered if anyone here could
> point me in the right direction as i try to make it work in a way that
> doesn't kill performance with mutex contention or i/o blocking.
>
> the current implementation stores state in a shm-segment rbtree. this
> works well so long as the amount of state doesn't exceed what was
> allocated at config time, but that's hard to guarantee under high load
> (and given the potentially long lifetimes for the tree nodes). is it
> possible to grow the shm size after config? and if not, is this a sign
> that i should actually be using the file system to cache this data
> instead?

There is no special function to grow shm size, if that's what you're
wondering. And I think keeping it simple is the right thing to do at this
point.

> i'm also a little confused as to how the module should schedule a
> recurring node-expiration callback that purges stale entries from the
> rbtree. at the moment the purge function is called at the top of every
> request, which feels like the wrongest possible way to do it. i've
> seen mention of the cleanup hook attached to the request's pool. is
> this a more appropriate place to run or are there other problems
> associated with that?

Well, it's up to you to decide. But since entries are completely unrelated
to the request you should probably move expiration somewhere else.

> these and other questions can be found here:
> https://github.com/samizdatco/ngx-http-auth-digest/issues
>
> personally i'm looking forward to a day where i no longer need apache
> if i want to use digest authentication, so i'd love to get this module
> to a reasonably trustworthy state. any feedback or guidance (or code!)
> you could offer would be a great help.