libmicrohttpd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]