The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.
The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.
Emil
···
On Sat, Jan 11, 2014 at 9:38 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.
Well, okay, then this was a (necessary) workaround. The RFC is pretty clear.
The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.
The sip.us 403 message doesn't include a challenge, hence no password dialog
to cancel the loop. Well, I'll look at it again so that we fail if there's
no challenge.
403s don't usually have a challenge, so this isn't going to change
much. IIRC, the thinking here was that resending a request after a 403
brings us back to a 401/407.
Emil
···
On Sat, Jan 11, 2014 at 10:02 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.
Well, okay, then this was a (necessary) workaround. The RFC is pretty clear.
The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.
The sip.us 403 message doesn't include a challenge, hence no password dialog
to cancel the loop. Well, I'll look at it again so that we fail if there's
no challenge.
The point of handling a 403 is to allow users to react to a wrong
password. A number of servers (such as Asterisk) return 403 for a bad
password.
Well, okay, then this was a (necessary) workaround. The RFC is pretty
clear.
The endless loop you describe does sound like a problem of course. If
that happens Jitsi should retry once and then remove any stored
passwords and ask the user for credentials at which point a "Cancel"
should break the loop. If this wasn't happening there must have been
an issue but I don't think that removing 403 handling is the right way
to address it.
The sip.us 403 message doesn't include a challenge, hence no password
dialog to cancel the loop. Well, I'll look at it again so that we fail
if there's no challenge.
403s don't usually have a challenge, so this isn't going to change
much. IIRC, the thinking here was that resending a request after a 403
brings us back to a 401/407.
Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1
With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)
Do you see something wrong with that? If so, could you please give me an
example?
Emil
Ingo
···
On Sat, Jan 11, 2014 at 10:02 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
I think that's exactly the way to address it. Thanks!
Emil
···
On Sun, Jan 12, 2014 at 1:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1
With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)
Do you see something wrong with that? If so, could you please give me an
example?
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.
···
On Sun, Jan 12, 2014 at 3:08 PM, Emil Ivov <emcho@jitsi.org> wrote:
On Sun, Jan 12, 2014 at 1:51 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
Yes, right. The commit message is wrong, it is actually checked if there was
no realm on the request that caused the 403. What I currently see with an
Asterisk 11.6/11.7 is:
1) Register (no auth)
2) 401 Unauthorized (with www-authenticate+realm)
3) Register (with authorization to realm from 401)
4) 403 Forbidden (due to wrong login, no realm)
5) (Jitsi asking for username+password)
6) Restart at 1
With sip.us:
1) Register (no auth)
2) 403 Forbidden (no www-authenticate)
3) abort of connection (due to no realm on initial register)
Do you see something wrong with that? If so, could you please give me an
example?
I think that's exactly the way to address it. Thanks!
Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate
on
403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.
I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup). Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?
Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate
on
403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.
I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup).
Yes, same experience for XMPP.
Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?
I am sure it's not the database config because. I haven't bisected so
I can't be 100% certain that the auth commit is at the root of this
but I feel quite confident this is when I started seeing it.
···
On Wed, Feb 12, 2014 at 3:08 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
Can you please send me the pcap over next time it happens?
Freundliche Grüsse,
Ingo Bauersachs
-- sent from my mobile
···
Le 12.02.2014 à 17:46, "Emil Ivov" <emcho@jitsi.org> a écrit :
On Wed, Feb 12, 2014 at 3:08 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
Subject: Re: [jitsi-dev] [jitsi-commits] master: Don't try to authenticate
on
403 responses (RFC 3261, 21.4.4) (18619e7)
It's interesting but since this change Jitsi gets to forget my
password at least twice a day. We'd have to look into this.
I never lost a password for SIP (contrary to XMPP, which regularly asks for
the password when there's a server hiccup).
Yes, same experience for XMPP.
Are you sure it's commit
4899b4127bcce25a40abcc4f4e29235fe84e7286 and not maybe the database based
config?
I am sure it's not the database config because. I haven't bisected so
I can't be 100% certain that the auth commit is at the root of this
but I feel quite confident this is when I started seeing it.