libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libmicrohttpd] Re: HTTP Digest Auth done


From: Christian Grothoff
Subject: [libmicrohttpd] Re: HTTP Digest Auth done
Date: Wed, 18 Aug 2010 10:18:37 +0200
User-agent: KMail/1.13.3 (Linux/2.6.32-trunk-vserver-amd64; KDE/4.4.4; x86_64; ; )

Hi!

On Tuesday 17 August 2010 22:00:20 Amr Ali wrote:
> Hi Christian,
> 
> I'm finally done with this module, I replaced the idea of an internal
> buffer that stores nonces with implementing a timeout mechanism for each
> nonce that is actually embedded into the nonce, so no need for increasing
> the memory footprint.

Nice -- if done right (so that clients cannot easily manipulate the 
timeout...).

> I however made the nonce timeout to be 300 seconds
> (which IMNSHO is quote enough), its already made as a macro that you can
> override with -DNONCE_TIMEOUT <SECONDS>.

Yuck.  How about giving the timeout as an argument in your API?
 
> I made an example C program for it as well, its completely based on
> minimal_example.c just changed/deleted a few calls.

Always good.  Do you also have a testcase and documentation (TexInfo) for the 
tutorial/manual?
 
> As for combining this with MHD, I wanted to discuss how you want this to be
> combined. The setup I have right now includes the files `digestauth.c' and
> `digestauth.h' in src/daemon/Makefile.am, same goes for
> `digest_auth_example.c'. I can change configure.ac to make it optional and
> not enabled by default, so if someone wants this, he/she has to compile it
> from source with something like "--enable-digest-auth"?

Sounds good, but I suspect the default should be "on" eventually: having --
disable-digest-auth (and maybe also --disable-post-processor) will make sure 
that only developers for embedded systems where code size is critical will 
disable it and "normal" packages, like say a Debian package for x86, have 
these enabled without forcing the maintainer to look up options.
 
> If you think this is good enough I'll make a patch for a the whole thing
> and send it your way. If not, please let me know what you have in your
> mind.

My mindset is getting to the point where new code needs to come with testcases 
and at least a little bit of documentation ;-).  Despite that request, I think 
you should send a first version of your patch now so that I can look over the 
API itself and give you feedback on that and the code.  That way, the test & 
documentation won't have to be rewritten if the API needs to be adjusted (like 
with the -D NONCE_TIMEOUT, which is just a bad hack that can really not stay).

Happy hacking

Christian



reply via email to

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