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 <[email protected]>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