libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] digest auth TLS and POST


From: A. Mark
Subject: Re: [libmicrohttpd] digest auth TLS and POST
Date: Fri, 3 Jan 2014 20:03:35 -0800


Thank you for the responses,

First problem was that I was using the git SVN mirror from here:

https://github.com/rboulton/libmicrohttpd which was very old 0.9.19...

So let's start over, I'm now using the SVN version: v0.9.33

For testing I'm using Firefox and Chromium or Web.

This is the skeleton of my Access_Handler:

access_handler(...){

 on first call do: authentication & request initialization & POST PROC initialization
 on subsequent calls do: request handling (POST,GET etc), and return pages and documents
}

Questions:

1) Getting a MHD_INVALID_NONCE from MHD_digest_auth_check() when authenticating on every request even when requests are one second apart. Is this due to the browsers inability to generate proper cnonce?  Both Chromium and Firefox exhibit this. (the same happens with digest_auth_example)

2) During a POST I will get a new connection from the MHD_AcceptPolicyCallback which does not happen when I'm not using authentication. Again is this a browser artifact? Or am I handling POST with authentication in the wrong order perhaps?

3) Since MHD_Connection is more of a "request context" than a "connection context" what if I needed to keep track of connection context info such as the number of requests made by a client (connection)?


Thank you!

Mark



On Fri, Jan 3, 2014 at 4:07 PM, Christian Grothoff <address@hidden> wrote:
On 01/04/2014 12:48 AM, A. Mark wrote:
> Hello,
>
> I'm using digest auth and TLS curently and I run into the issue with POST
> requests. This is how my acces_handler works currently:
>
> access_handler(...){
>
>  check_initial_call...{
>      setup POST processor
>      setup other request specific structs}
>
>  successive_calls{
>    check digest auth and fail if necessary...
>     handle requests POST,GET,DELETE etc...
>    return html/xml pages}
> }
>
>
> I'm getting these:
>
> "Failed to receive data: A TLS fatal alert has been received."
>
> once in a while on GET requests.

You might want to give details on what TLS implementation you're using for
the client --- and talk to the GnuTLS developers, as MHD really just leaves
the handshake to GnuTLS.

> I'm also getting:
>
> MHD_INVALID_NONCE from MHD_digest_auth_check once in a while, not sure that
> this is normal for every other request. Seems like the client is not
> generating cnonce properly?

Maybe, I don't know anything about your client.  Note that nonces also
expire (eventually).

> POSTs always fails with:
>
> "Internal application error, closing connection."
>
> due to MHD_NO returned by MHD_queue_auth_fail_response.

Well, it's a bit hard for me to analyze based on this --- you should
probably first look at MHD_queue_auth_fail_response to figure out
why/where you get the error code from...


> I'm able to run everything the if I run the access handler this way:
>
> access_handler(...){
>
>  check_initial_call...{
>      setup POST processor
>      setup other request specific structs...
>      check digest auth and fail if necessary{}
> }
>
>  successive_calls{
>    handle requests POST,GET,DELETE etc...}
> }
>
> however obviously each requests is handled by a new connection, not ideal...

I'm not sure I understand, but note that the "MHD_Connection" is actually
mostly inaptly named --- "MHD_Connection" should really be called
"MHD_Request",
as the same TCP connection may persist over multiple "MHD_Connections". As
an application, you can currently not even really always tell if a second
request is using a fresh TCP/SSL connection, or using pipelining.

> The way it should work is that each request is authenticated once on the
> same connection context. Any suggestions are appreciated.

I'm not sure I understand what you mean by "connection context".

Finally, you might want to clue us into which version of MHD you're using,
and you might want to clarify if the issue disappears if you disable the
use of TLS.  Naturally, providing a test case would also help me understand
your issue better.


Happy hacking!

Christian


reply via email to

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