[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] HTTP Digest Auth and Internal synchronization
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] HTTP Digest Auth and Internal synchronization |
Date: |
Sat, 14 Aug 2010 02:12:14 +0200 |
User-agent: |
KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) |
On Saturday, August 14, 2010 12:32:23 am Amr Ali wrote:
> I mentioned before that I'm working on an internal module for MHD,
> obviously from the subject it is Digest Auth. I'm having a decision
> problem at how I should approach making sure that the "nc" or nonce
> counter should be increased for subsequent requests.
>
> Can I use mutexes (or spinlocks since the process itself takes so much less
> time to put a thread into sleep and bring it back up again) to avoid race
> conditions between different connections or requests? or there is some
> other way you've developed internally to help with such situations that I
> could make use of.
You should use pthread lock/unlock. That's the only way to make sure that
what you do is portable (within the realm of platforms that MHD is supposed to
support at least...).
> Also I want to support mitigations for replies attacks, but that would take
> a couple of memory pages to contain recently used server nonces. Are there
> guidelines or general project policy that would discourage increasing the
> memory requirements? (in most cases only 100k of extra memory foot print
> would be enough to track a big amount of nonces)
I'd say the only guideline is to not use more than needed (compact
representation) and, for this kind of thing, to allow the user to specify the
size of the cache (including zero for no history). Naturally, you should also
always check the return code from malloc for NULL and handle failures nicely.
> It can be an optional
> feature or Digest Auth as a whole to be optional like HTTPS/SSL. I'm
> asking so if you decided to put this upstream there won't be any conflicts
> of interest.
Well, I don't see how you get the idea that there might be a "conflict of
interest". Now, what I'm not sure about is how this should be added to MHD
given that I see this as an orthogonal feature that really does not need to be
in the core library. Naturally, the same applies to the MHD PostProcessor
API. So if your code can be made similarly "separate" and "optional" (and
easily removable for those who really need a tiny footprint and don't want
this particular feature), that'd be great.
Happy hacking,
Christian