With an open DM installation login doesn't work

[jri]

The webclient shows "Logged in as ..." but actually no session is created at server-side.

An open DM installation is one with

dm4.security.read_requires_login=false
dm4.security.write_requires_login=false

Thank you, Malte, for reporting!

[Jörg Richter]

Access Control: fix login (#475).

Login works also with an open DM installation.

An open DM installation is one with

dm4.security.read_requires_login=false
dm4.security.write_requires_login=false

Close ticket 475.

• Changeset: ca61964a27e6757848e638c3bafc9374c6aff45c
• URL: ​https://github.com/jri/deepamehta/commit/ca61964a27e6757848e638c3bafc9374c6aff45c

[Malte]

With these new settings (both on false), I have 2 observations when running the latest commit on the deepamehta 'master' branch:

• any of my requests to the deepamehta-webclient leaves me "Logged in as admin", even though ' i did not log in before
• i cannot logout from the deepamehta-webclient anymore, resp. when I reload, I am logged in again

I am using Chromium. Is this different for you?

[Malte]

So from the deepamehta-log I can see when requesting the deepamehta-webclient and running dm under the above mentioned settings:

• I never see a "Logout.. (successfull).." there
• With each request "admin" logs in succesfully and a new session is created magically

[Malte]

• When I call the '/accesscontrol/logout' interface (through my notes interface), the "Logging out from session xxx" appears in my deepamehta-log

[jri]

Replying to Malte:

With these new settings (both on false), I have 2 observations when running the latest commit on the deepamehta 'master' branch:

• any of my requests to the deepamehta-webclient leaves me "Logged in as admin", even though ' i did not log in before
• i cannot logout from the deepamehta-webclient anymore, resp. when I reload, I am logged in again

I am using Chromium. Is this different for you?

This comes as a complete surprise to me.
I've carefully tested all cases with at least Safari, Firefox, and Chrome, and all works properly.
I can't reproduce your observations. However, I've no Chromium running on my mac.

=> Try restarting Chromium. Clear all caches.
=> Try another browser. Does it work for you?
If so, you can proceed with that browser. And I'll could investigate about Chromium in the meantime. But to isolate the problem please let me know first if you can approve that it works in Firefox or Chrome.

[Malte]

Thanks for your help, indeed, restarting Chromium did the trick for me. And with Firefox 21.0 I seem to have the same issue, while I now checked the "Authorization"-Header and it was always sent along from my very first request on.

But the issue remains dubious to me, specifically how come that in my browser "open for long time" I do experience the following side-effects, which vanish through restarting the browser.

• the "logout" request is not performed properly (e.g. from the webclient)
• thus a login with any different username than the one currently logged in is also not possible
• each request to (e.g. the webclient) creates a new session, see:

g! 10.06.2013 01:30:18 de.deepamehta.plugins.topicmaps.model.Topicmap <init>
INFO: Loading topicmap 2255
10.06.2013 01:30:22 de.deepamehta.plugins.accesscontrol.AccessControlPlugin logout
INFO: ##### Logging out from session 82qeyvu303vh11n6gqx72unzf (username=admin) NOTE: This output came from my (in the meantime) restarted Chromium session on the same server)
10.06.2013 01:30:22 de.deepamehta.plugins.accesscontrol.AccessControlPlugin tryLogin
INFO: ##### Logging in as "admin" => SUCCESSFUL!
      ##### Creating new session 1cgcujilmuhzi13t0rpujm00nl (username=admin)
10.06.2013 01:30:22 de.deepamehta.plugins.accesscontrol.AccessControlPlugin tryLogin
INFO: ##### Logging in as "admin" => SUCCESSFUL!
      ##### Creating new session kjo30w82lv5l6ncr9w4ij897 (username=admin)
10.06.2013 01:30:23 de.deepamehta.plugins.topicmaps.model.Topicmap <init>
INFO: Loading topicmap 2255
10.06.2013 01:32:27 de.deepamehta.plugins.accesscontrol.AccessControlPlugin tryLogin
INFO: ##### Logging in as "admin" => SUCCESSFUL!
      ##### Creating new session 1p6v17mqupydi1bhi8o90fuhvh (username=admin)
10.06.2013 01:32:42 de.deepamehta.plugins.accesscontrol.AccessControlPlugin tryLogin
INFO: ##### Logging in as "admin" => SUCCESSFUL!
      ##### Creating new session hiyfwhocr9s1jv7p7px2mrui (username=admin)
10.06.2013 01:32:59 de.deepamehta.plugins.topicmaps.model.Topicmap <init>
INFO: Loading topicmap 2255
10.06.2013 01:33:00 de.deepamehta.plugins.accesscontrol.AccessControlPlugin tryLogin
INFO: ##### Logging in as "admin" => SUCCESSFUL!
      ##### Creating new session 1anc36zqbt7kiwaa7k51a82mw (username=admin)

Maybe that the "Logout request.. " failing silently gives us a hint, but I need to understand the issue better. For now I can work on. Thanks!

[jri]

Replying to Malte:

With these new settings (both on false), I have 2 observations when running the latest commit on the deepamehta 'master' branch:

• any of my requests to the deepamehta-webclient leaves me "Logged in as admin", even though ' i did not log in before
• i cannot logout from the deepamehta-webclient anymore, resp. when I reload, I am logged in again

I am using Chromium. Is this different for you?

Meanwhile I played around more and I can reproduce your observation in this scenario:

1. Start a closed DM installation (both settings true)
2. Start the webclient. The browser's login dialog appears.
3. Login as usual
4. Stop DM without logging out
5. Start an open DM installation (both settings false)
6. Now logout. The Webclient shows logged out status, but actually you're still logged in.
7. Press reload. The Webclient shows logged in status

In this scenario there is no way to logout except restarting the browser.
So the simple solution is: restart the browser.

Note: you should logout before you stop DM and change its configuration.

Explanation: with every request a web browser keeps sending the Authorization header with the credentials entered in the browser's login dialog. This is normal behavior of every web browser and reflects the statelessness of HTTP. HTTP resp. the web browsers have no logout semantics. DM logout workaround described in #471 doesn't work if you change DM's configuration while still logged in.