Authentication error or maybe it isn't? - no user/password was provided

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:
199.7.156.144 - - [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” “-”

199.1.1.1 - MYUSERID [20/Oct/2013:15:38:50 -0400] “OPTIONS
/USERID/testcalhttps/ HTTP/1.1” 200 5 “-” “CalDAV-Sync (Android) (like
iOS/5.0.1 (9A405) dataaccessd/1.0) gzip” “-”

199.1.1.1 - MYUSERID [20/Oct/2013:15:38:50 -0400] “PROPFIND
/USERID/testcalhttps/ HTTP/1.1” 207 1646 “-” “CalDAV-Sync (Android)
(like
iOS/5.0.1 (9A405) dataaccessd/1.0) gzip” “-”

199.1.1.1 - MYUSERID [20/Oct/2013:15:38:51 -0400] “REPORT
/USERID/testcalhttps/ HTTP/1.1” 207 8525 “-” “CalDAV-Sync (Android)
(like
iOS/5.0.1 (9A405) dataaccessd/1.0) gzip” “-”

199.1.1.1 - MYUSERID [20/Oct/2013:15:38:53 -0400] “PUT
/USERID/testcalhttps/e024b939-a58c-4b42-8f65-77d75942541c.ics HTTP/1.1”
201
5 “-” “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: 199.1.1.1, 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.

Thanks in advance!

Joseph

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,243871,243871#msg-243871

On Sun, Oct 20, 2013 at 04:17:34PM -0400, dalmolin wrote:

Hi there,

/USERID/testcalhttps/ HTTP/1.1" 200 5 “-” “CalDAV-Sync (Android) (like
iOS/5.0.1 (9A405) dataaccessd/1.0) gzip” “-”

That indicates that the client made a http request, was told “need
auth”,
and then repeated the request with authentication credentials which
were accepted.

That’s pretty much how things are supposed to work.

The only odd thing I see is that the source IP address changed between
the two requests.

error.log entries:
2013/10/20 15:38:49 [error] 6797#0: *241 no user/password was provided for
basic authentication, client: 199.1.1.1, server: , request: “OPTIONS
/USERID/testcalhttps/ HTTP/1.1”, host: “mysserver.com:1905

That matches what access.log shows.

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.

Either accept that the phone is correct, and all of the other clients
are sending your password before they were asked for it; or change the
phone app to take the same shortcut.

It probably isn’t a config setting in the phone app.

So it looks like the
userid/password are processed after the first request somehow.

Yes; the phone doesn’t send the userid/password on the first request.

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.

Probably not. Does the laptop via the internet show the same behaviour?

f

Francis D. [email protected]

It’s something a lot of people are bumping on.

401 HTTP covers both failed and missing authentication but isn’t
possible
for Nginx to differentiate those states and thus only generate an error
message on a failed (ie not empty credentials, either user or password
containing something) attempt?
That would make the error log more efficient as parsing it would provide
more directly failed attempt to access a particular resource.

Is it the standard way of doing things or is it your own?
Are there some use cases or reasons against differentiating 401 answers?

B. R.

Hello!

On Sun, Oct 20, 2013 at 04:17:34PM -0400, dalmolin wrote:

/USERID/testcalhttps/ HTTP/1.1" 401 194 “-” “CalDAV-Sync (Android) (like
iOS/5.0.1 (9A405) dataaccessd/1.0) gzip” “-”

[…]

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.


Maxim D.
http://nginx.org/en/donation.html

Hello!

On Sun, Oct 20, 2013 at 05:17:37PM -0400, B.R. wrote:

Are there some use cases or reasons against differentiating 401 answers?
The difference is already here.

The message “no user/password was provided for basic
authentication”, as in original message, means exactly that: there
are no credentials provided.

On failed authentication, the “user …: password mismatch”
message is logged. On unknown user, the “user … was not
found in …” message is logged.

It might make sense to downgrade the “no user/password …”
message severity. Not sure though.


Maxim D.
http://nginx.org/en/donation.html

Thanks Maxim!

I didn’t really pay attention to the difference in the error messages.
Thanks for remembering them.

The question of the severity of the last message has no simple answer
I’m
afraid, since it depends on the use case.
Maybe someone wishes to log any attempt to access a protected ressource
?
Not sending credential is then considered as an ‘error’
Maybe someone only consider a ‘void’ attempt as an error if it’s not the
1st access in a short time. The problem I see here is there is that HTTP
having no memory (stateless), there is no way has knowing such thing as
‘1st access’ or not.
More than that, I think that’s user-centric definition, not really an
‘error’ as such.

The main problem here is that this message is generated when the
credentials are asked for, which is a normal flow of a use-case scenario
for a standard protected resource.
Filtering for errors against a specific resources will then generated
loads
of unmeaningful entries, potentially hiding interesting ones.

1°) Since cancelling sending credentials when requested generates 403,
there must be a way for Nginx to differentiate 1st connection attempt to
the followings: can’t that be used to avoid logging an error message on
1st
attempt (and log it in access log instead)? Downgrading this message
severity for this case.
2°) As an extra feature, is there a way for Nginx to remember (at cost
of
memory) access attempts on (conf defined) short time, logging errors
only
if a trigger made of (conf defined) multiple attempts is reached?

B. R.

On Mon, Oct 21, 2013 at 10:15:51AM -0400, B.R. wrote:

Hi there,

Maybe someone wishes to log any attempt to access a protected ressource ?
Not sending credential is then considered as an ‘error’

Access log includes $status = 401.

Maybe someone only consider a ‘void’ attempt as an error if it’s not the
1st access in a short time.

Access log includes $status = 401, and the user analysing the log can
choose to ignore the first of a set in a short time.

The main problem here is that this message is generated when the
credentials are asked for, which is a normal flow of a use-case scenario
for a standard protected resource.

Access log includes $status = 401 and $remote_user = -, probably.

Filtering for errors against a specific resources will then generated loads
of unmeaningful entries, potentially hiding interesting ones.

Access log includes $status = 401 and $remote_user != -, probably.

(There are cases when an “Authorization: Basic” header will include a
value that shows as “-”, but they probably aren’t worth worrying about
if you are looking for “normal” bad authentication attempts.)

  1. Since cancelling sending credentials when requested generates 403,

No, it doesn’t.

Cancelling sending credentials will usually get the browser to show
you the 401 page that nginx sent on the previous request, which had
invalid credentials.

there must be a way for Nginx to differentiate 1st connection attempt to
the followings: can’t that be used to avoid logging an error message on 1st
attempt (and log it in access log instead)? Downgrading this message
severity for this case.

HTTP is stateless.

Each request includes appropriate credentials, or it doesn’t.

You can drop the first-log-line-in-a-sequence in your analysis program,
where you decide exactly what you mean by sequence. nginx should not
decide what you consider a sequence.

  1. As an extra feature, is there a way for Nginx to remember (at cost of
    memory) access attempts on (conf defined) short time, logging errors only
    if a trigger made of (conf defined) multiple attempts is reached?

A patch would probably be considered; but I suspect that it’s going to
be easier for whatever is reading the full log file to be told which
lines to heed and which to ignore.

f

Francis D. [email protected]

On Mon, Oct 21, 2013 at 10:34 AM, Francis D. [email protected]
wrote:

1st access in a short time.
Filtering for errors against a specific resources will then generated
loads
of unmeaningful entries, potentially hiding interesting ones.

Access log includes $status = 401 and $remote_user != -, probably.

(There are cases when an “Authorization: Basic” header will include a
value that shows as “-”, but they probably aren’t worth worrying about
if you are looking for “normal” bad authentication attempts.)

​Thanks for all those tips. The access log has all the required
information
contained in it already, then.

1°) Since cancelling sending credentials when requested generates 403,

No, it doesn’t.

Cancelling sending credentials will usually get the browser to show
you the 401 page that nginx sent on the previous request, which had
invalid credentials.

​Sorry for this, that was pure conjectures. Thanks for the explanation.

there must be a way for Nginx to differentiate 1st connection attempt to
the followings: can’t that be used to avoid logging an error message on
1st
attempt (and log it in access log instead)? Downgrading this message
severity for this case.

HTTP is stateless.

Each request includes appropriate credentials, or it doesn’t.

​I know, that’s why I was talking about creating some ‘memory’ (mapping
against IP addresses?)

You can drop the first-log-line-in-a-sequence in your analysis program,

where you decide exactly what you mean by sequence. nginx should not
decide what you consider a sequence.

​Talking about what Nginx should or shoudn’t decide for the user, ​
​what about the error log entry when a 401 is accessed? :o)
As you mentioned earlier, this is already logged in the access log. What
about Maxim was suggesting: downgrading the message importance? Maybe
that
would mean stopping logging that in the error logfile.

2°) As an extra feature, is there a way for Nginx to remember (at cost of
memory) access attempts on (conf defined) short time, logging errors only
if a trigger made of (conf defined) multiple attempts is reached?

A patch would probably be considered; but I suspect that it’s going to
be easier for whatever is reading the full log file to be told which
lines to heed and which to ignore.

​As stated, that’s extra, and that’s a new feature. More important
trouble
must eat your time first.
That’s not really adressing our issue best, so for now, a redifinition
of
what Nginx should decide by itself or not ​
​would probably be more effectual.​

What about Maxim’s proposition then? Is there something we missed about
mechanics in accessing protected resource?

B. R.

Thank you Francis… it all makes sense! By the way, I modified the IP
addresses before posting which explains why they changed… :slight_smile:

Joseph

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,243871,243927#msg-243927

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs