Authentication error or maybe it isn't? - no user/password was provided
mdounin at mdounin.ru
Sun Oct 20 20:51:36 UTC 2013
On Sun, Oct 20, 2013 at 04:17:34PM -0400, dalmolin wrote:
> I have set up an Nginx as a front end to manage secure connection and
> authorization for the Radicale calendar server which I use to synch my
> Lightning calendar on my desktop, laptop and Android phone (it uses the
> Caldav Synch app). It all works fine after a long and steep learning curve
> for me at least. One strange thing I have noticed is that I keep getting an
> error in the Nginx error log for the Android device, here are the
> abbreviated logs from Nginx's access.log and error.log:
> access.log entries:
> 126.96.36.199 - - [20/Oct/2013:15:38:49 -0400] "OPTIONS
> /USERID/testcalhttps/ HTTP/1.1" 401 194 "-" "CalDAV-Sync (Android) (like
> iOS/5.0.1 (9A405) dataaccessd/1.0) gzip" "-"
> error.log entries:
> 2013/10/20 15:38:49 [error] 6797#0: *241 no user/password was provided for
> basic authentication, client: 188.8.131.52, server: , request: "OPTIONS
> /USERID/testcalhttps/ HTTP/1.1", host: "mysserver.com:1905"
> The userid and password were correctly entered during setup of the calendar
> on the client and as I said it all works fine... I can add, delete, modify
> calendar entries and synch across all my devices. But I keep getting this
> pesky error when using my phone.
> I noticed that in the access.log the first access corresponds to the error
> message in the error log.... and then there are four more access messages
> with my USERID appended to the IP address. So it looks like the
> userid/password are processed after the first request somehow. Also, it may
> be helpful to know that the phone is connecting to Nginx via the internet
> and portforwarding via my router to the server. Might this error message
> simply be the result of the way I am accessing the server... as I don't get
> the same error when I access the server via the LAN and my laptop.
It looks like your client doesn't provide auth credentials on
first request, but does so on subsequent ones after a 401
response. It's likely coded to work this way.
More information about the nginx