Logout doesn't work

[jri]

When logging out the "logged-in" status (upper/right corner) disappears but the user actually remains logged in. While logging out in the the server-log you see 2 (!) new sessions are created immediately.

This happens only in case the dm4.security.read_requires_login DM config property is set to true. Otherwise Logout works fine.

[jri]

I've further isolated the issue. It's not related to the DM Karaf distro at all.

The issue is related to the browser's own login dialog. Its appearance in turn is related to the dm4.security.read_requires_login DM config property.
(The DM Karaf distro sets it true by default. In contrast, the DM standard distro sets it false by default.)

This is a known HTTP problem. HTTP provides no logout semantics. The browser caches the information entered in the browser's own login dialog and re-sends it with every request. There is no way to clear that cache besides quitting the browser.

A while ago I read about a possible workaround: as far as I remember it involves an AJAX request to be sent after the logout request, and enforcing a 401 (by sending dummy credentials in the Authorization header). The workaround is based on the fact that (in contrast to a "normal" request) an AJAX request with a 401 response does *not* bring up the browser's own login dialog but resets the cached credentials. (I'm not fully sure about this, but there is such a workaround. It is also utilized by the Trac software.)

I will try to utilize that workaround for DM as well.

Hint: when dm4.security.read_requires_login is set to false the problem does *not* occur. Logout works fine in this case. The browser's own login dialog is not involved then.

[jri]

Access Control module: fix logout (#423).

Logout works for "private" DM installations too.

As a reminder:
The webclient of a "private" DM installation is only be visible/usable when logged in. The browser brings up its own login dialog *before* the DM Webclient actually appears. And once logged out, the Webclient GUI disappears and leaves a blank browser window.
A DM installation is made "private" by setting the dm4.security.read_requires_login config property to true. See

pom.xml (Development setup)
/conf/config.properties (Standard Distribution)
/etc/system.properties (Karaf Distribution)

By default the Standard Distribution sets up "non-private" DM installation.
By default the Karaf Distribution sets up a "private" DM installation.

To fight the "HTTP logout" problem in conjunction with a "private" DM installation the following workaround is now utilized: a /accesscontrol/logout request replies with 401 Authorization Required. This emulates a HTTP logout by forcing the webbrowser to bring up its login dialog. This time the login dialog is pure dummy (it can't be used to login again). The login dialog just forces the browser to forget the former Authorization information. The user is supposed to press "Cancel". The webclient shuts down the GUI then and the browser window just shows "You're logged out now".

At the moment the login dialog appears the user is actually logged out already (the session is invalidated), so it is safe to close the browser window immediately, without pressing "Cancel".

In the browser's error console the 401 response is reported as an error. This can safely be ignored.

The dummy login dialog appears at least in Firefox and Chrome. However, in Safari (tested with 5.1.7 as of Mac OS X 10.6.8 Snow Leopard) the dummy login dialog does *not* appear. Apparently Safari suppresses the login dialog when the 401 is a result of an AJAX request.

Conclusion: with Safari logging out from a "private" DM installation works perfectly fine (besides a 401 error is reported). With Firefox and Chrome the possibility of a true HTTP logout comes at the price of a dummy login dialog. With a "non-private" DM installation logout is no problem at all.

This ticket is regarded as resolved.

BREAKING CHANGE

Access Control API:

• logout() (resp. /accesscontrol/logout) returns void (instead of boolean). For a "private" DM installation the response is 401 Authorization Required.

See ticket 423.

Changeset ba807176d7dfbbba691862e091cd165ea5dd24e2