Forum

Hi Hugo,

We turned on digest authentication on all clients(curl based remote client programs) before we turn on the digest authentication on Hiawatha Server.
This was done to make sure all clients will have the new digest auth enabled software before we turn in on the feature on Wenserver.
However this is causing a problem for us.
1) libcurl client tried to initiate a digest auth handshake with server (packet with Content length 0)
2) Hiawatha receives the packet, but as there is no digest auth enabled on Hiawatha, passes the packet to fcgi app which matches condition.
3) FCGI app doesn't know how to handle a packet with content-legnth 0.

My question is how can we configure Hiawatha respond to digest auth packet properly without passing it to the fcgi application.


Hiawatha version:
Operating System:

Use the PasswordFile and LoginMessage options to enable Digest HTTP Authentication:

PasswordFile = /full/path/to/.passwordfile
LoginMessage = Some message

The text set via Login Message is the realm for HTTP Digest authentication. The entries for the password file can be created via the wigwam(1) tool.

Sorry Hugo.. I think I did not explain the situation properly.
I know how to enable the digest auth properly.
We want to phase out the release.
Phase I.
make all clients in field ready with digest authentication.
Phase 2.
After 1 or 2 months(once all clients have received the updated firmware with digest auth capabilty), release the server with digest auth enabled.
Now please go through my initial email,

Thanks again

If your clients work correctly, they should only use Digest HTTP authentication when the server asks for it.

libcurl should not make the initiate digest auth handshake i guess
using custom 401 error page results in error in digest/basic auth when using php in it, as the code should be processed by hiawatha and not by fcgi.
also you need to set the acceslist to pwd for digest.. and the ones for put and get.