[heroes] Re: [opensuse-factory] Auto-logoff on wiki/OBS
Hello, IMPORTANT: I just logged out everybody from the wiki and other services behind login2.o.o. That's a one-time event, please just login again - and read on if you are interested in the technical details ;-) Am Freitag, 1. November 2019, 09:17:15 CET schrieb Axel Braun:
I have since latest the problem, when I log in to the openSUSE-wiki in a new tab, I got logged-off in a different tab from OBS...and vice versa. Not specific to the latest version of Firefox...happening iwth older ones as well
That's independent of the browser you use, and looks like a clash of cookie names between login.o.o (used for OBS) and login2.o.o (used for the wikis). Logging in on the wiki, I just got the following cookie: (shortened): openSUSE_session: 3e3b3fa3f... I then logged in into OBS and got another cookie (shortened again): openSUSE_session: 905531e8... Note that both login.o.o and login2.o.o use the same cookie name ("openSUSE_session"), but since they are independent servers, don't know about each other's login sessions. Therefore it's not surprising that only the last login can win :-( The obvious solution is to change the cookie name on one of the servers. Since I only have access to login2.o.o, I took the easy way and changed it there instead of annoying someone with access to login.o.o. With this change applied, you'll be able to be logged in to the wikis and OBS at the same time ;-) Regards, Christian Boltz -- Aber da du unter den Hardcore Freaks noch in der "extrem-hardcoring" Ecke zu finden bist (*), wird die Kluft zwischen deinen Anforderung und dem was der Markt hergibt noch grösser als bei den meisten anderen. (*)wer sonst hier in der Liste liest sendmail.cf files als Abendlektüre! [Andreas Kyek in suse-linux über David Haller] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Am Samstag, 2. November 2019, 19:23:01 CET schrieb Christian Boltz:
With this change applied, you'll be able to be logged in to the wikis and OBS at the same time
Thank you for fixing Christian! Axel -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On 11/2/19 7:23 PM, Christian Boltz wrote:
Note that both login.o.o and login2.o.o use the same cookie name ("openSUSE_session"), but since they are independent servers, don't know about each other's login sessions. Therefore it's not surprising that only the last login can win :-(
The obvious solution is to change the cookie name on one of the servers. Since I only have access to login2.o.o, I took the easy way and changed it there instead of annoying someone with access to login.o.o.
Isn't the obvious solution to let the application set the cookie's 'Domain' attribute? A properly written application should do that. Ciao, Michael. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello, Am Sonntag, 3. November 2019, 00:18:34 CET schrieb Michael Ströder:
On 11/2/19 7:23 PM, Christian Boltz wrote:
Note that both login.o.o and login2.o.o use the same cookie name ("openSUSE_session"), but since they are independent servers, don't know about each other's login sessions. Therefore it's not surprising that only the last login can win :-(
The obvious solution is to change the cookie name on one of the servers. Since I only have access to login2.o.o, I took the easy way and changed it there instead of annoying someone with access to login.o.o.
Isn't the obvious solution to let the application set the cookie's 'Domain' attribute?
A properly written application should do that.
I'm afraid it isn't that easy ;-) login.o.o and login2.o.o act as login proxies [1] for several *.o.o domains, and the browser sees domains like en.o.o and build.o.o (but not login.o.o or login2.o.o). From a browser's viewpoint, the session cookie gets sent by e. g. en.o.o or build.o.o. This also means restricting the cookie to a specific subdomain [2] would break single sign-on [3]. This leaves using different cookie names as the way to go ;-) Regards, Christian Boltz [1] To be exact, as a reverse proxy, somewhat similar to haproxy or apache mod_proxy - but with some additions like - the /ICSLogin/ part serving and handling the login page - sending out and handling the session cookie - adding headers with the username etc. when forwarding the request to the actual servers (so that for example the wiki server knows who is logged in, but never has to see or check any password) [2] I guess your idea was to restrict the session cookie to login2.o.o? My explanation should make clear why that won't work - actually it would completely break the login because the browser would never send a cookie restricted to login2.o.o to en.o.o. [3] Actually we have a triple sign-on ;-) using login.o.o for OBS, login2.o.o in the heroes network for the wikis etc., and another login server in Provo for bugzilla and the forums. This means that in worst case you have to login 3 times if you want to use all these services. -- <coolo> Ilmehtar: in rails you don't javascript, you jquery <coolo> or even worse, you coffee <ancor> Ilmehtar: coolo is right. I always use jquery <ancor> but I'm not still used to coffee <vad> tea, then? [from #opensuse-project] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On Sun, Nov 03, 2019 at 02:00:37AM +0100, Christian Boltz wrote:
Hello,
Am Sonntag, 3. November 2019, 00:18:34 CET schrieb Michael Ströder:
On 11/2/19 7:23 PM, Christian Boltz wrote:
Note that both login.o.o and login2.o.o use the same cookie name ("openSUSE_session"), but since they are independent servers, don't know about each other's login sessions. Therefore it's not surprising that only the last login can win :-(
The obvious solution is to change the cookie name on one of the servers. Since I only have access to login2.o.o, I took the easy way and changed it there instead of annoying someone with access to login.o.o.
Isn't the obvious solution to let the application set the cookie's 'Domain' attribute?
A properly written application should do that.
I'm afraid it isn't that easy ;-)
login.o.o and login2.o.o act as login proxies [1] for several *.o.o domains, and the browser sees domains like en.o.o and build.o.o (but not login.o.o or login2.o.o).
From a browser's viewpoint, the session cookie gets sent by e. g. en.o.o or build.o.o. This also means restricting the cookie to a specific subdomain [2] would break single sign-on [3].
This leaves using different cookie names as the way to go ;-)
Regards,
Christian Boltz
[1] To be exact, as a reverse proxy, somewhat similar to haproxy or apache mod_proxy - but with some additions like - the /ICSLogin/ part serving and handling the login page - sending out and handling the session cookie - adding headers with the username etc. when forwarding the request to the actual servers (so that for example the wiki server knows who is logged in, but never has to see or check any password)
If you can pass on the login name you can pass on the domain as well, so it knows for which domain you want to set the cookie, right? The obvious downside is that if the server serves multiple domains you would have to contact it several times separately to set cookies for different domains. It's not like it does not happen in practice, anyway. I need to log in to bugzilla.o.o and bugzilla.suse.com separately, and also separately to the wiki and to the build service. Which also means if one of the bugzilla cookies gets broken I can use the other domains to get to bugzilla.. Thanks Michal -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On 11/3/19 2:00 AM, Christian Boltz wrote:
I'm afraid it isn't that easy ;-)
login.o.o and login2.o.o act as login proxies [1] for several *.o.o domains, and the browser sees domains like en.o.o and build.o.o (but not login.o.o or login2.o.o).
Ah, I forgot this strange SSO-by-reverse-proxy setup. Is it still based on what Novell called iChain? I guess this is an important point to discuss at the face-to-face heroes meeting in Nuremberg. Ciao, Michael. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
participants (4)
-
Axel Braun -
Christian Boltz -
Michael Ströder -
Michal Suchánek