Log-in dialog is displayed on public page after log-out
| Project: | Secure Site |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
I'd like to use securesite to control access to part of a Drupal site and keep the rest public. I've set up a new Drupal 4.7.4 site for testing, created the first page and given the "access content" permission to the anonymous user role. Now the / page is shown to everyone who comes to the site, along with Drupal's login block.
A user can log in and log out, and then he's back at /.
If I enable securesite with the HTML login form and tell it to bypass every page except "protected/*", everything is the same as before.
However, if I enable securesite with webbrowser HTTP-AUTH security (with or without the browser logout workaround), then the user can still log in via the Drupal login block, but when he logs out, he gets the password dialog. If he clicks [Cancel], he's redirected to /logout and shown securesite's password reset form. Is there a way to avoid the password dialog and instead redirect to /, as if securesite weren't enabled?
#1
That's a bug. I will see about putting a patch together for you. Its a tricky one, because on logout securesite will need to check the bypass filter pages and this is also a problem because I need to check where the user has come from not the page they are already on. I actually don't know how to solve this problem. With the login form their is no problem, but with http-auth the way to log somebody out is to show them the dialog again as that is the only way to reset the http-auth variables.
What do you want to use, the html login form or http-auth currently you cant use both.
#2
With the login form it works just fine.
The problem is with HTTP-AUTH. But HTTP-AUTH has the advantage that it supports the http://user:password@example.com/ standard mechanism, and that's why I'd prefer to use HTTP-AUTH.
I've also done some testing with the httpauth module. It seems to be able to log out cleanly without redisplaying the dialog (but it has other properties that make it less useful for my needs).
#3
Just a thought: In the present scenario, authentication was done through the Drupal login block, so the HTTP-AUTH variables shouldn't be set and shouldn't need resetting...
httpauth does indeed fail to clear the variables: if you go back to a url that needs authorizing, you're logged in automatically. Given httpauth's focus this may be less of a problem than it would be for securesite -- securesite should clear the HTTP-AUTH variables, but only if needed.
#4
The problem with the http-auth variables is that you cant control them, can only set and unset using the auth dialog. So if you don't present the user with the auth dialog on logout then the variables are still set with last login info, so if the user had to refresh the browser they would re-login.
I am working on a way to redirect back to the home page but still show the auth dialog so if the user were to click cancel they would be on the home page (/) and not the logout page. If that page is not protected the home page should load normally.
#5
The problem is knowing how the user was authenticated.
#6
Is it possible to record this in the PHP session?
#7
I have experienced the same behavior (auth dialog on logout).
I have attached a simple workaround (patch agains rev. 1.24.2.5). It doesn't solve the other http auth issues mentioned here, but it makes sure that the dialog isn't displayed. Not an ideal solution, but it may prove useful to some.
#8
Yes, this works fine for me under IE6 and FF2, thank you. I wonder whether it can cause problems on other browsers?
#9
Hmm, this is odd — it worked fine at first, but after a while I got into a state where I couldn't log out anymore (with FF). I put back securesite-dialog.tpl.php with this code at the top and removed the #7 patch, cleared the cookie and the HTTP authorization, and now FF is back to normal.
A patch entirely within the Secure Site code would have been nice, but this is tricky business...
#10
#11
The popup must be generated when an HTTP-AUTH session is ended, in order to clear the credentials cache for web-browsers. Otherwise, on the next visit to an HTTP-AUTH protected URL, the browser will supply credentials without the user having to log in again.
I'm providing a patch which marks sessions which are initiated from HTTP-AUTH dialogues in the
$_SESSIONvariable for the session. The cache-clearing HTTP AUTH dialogue on logout is then generated only for these HTTP-AUTH sessions.Also, the patch provides a cron hook which clears entries in the session table after a configurable amount of time.
The patch is against version 1.2.2.26, DRUPAL 4.7.
#12
#13
#227988: login form after logout has a patch similar to #11 for the 5.x branch
#14
NaX proposed the correct solution in #4. Any other solution would cause more problems.
#15
But that is not satisfactory. If the user has not logged in through the HTTP-AUTH dialog but through the Drupal login block, then there are no cached credentials that would need to be reset. The dialog must not be displayed in that case, because it unnecessarily confuses innocent users.
I've fixed this problem by deploying securesite_dialog.tpl.php and inserting
<?phpif ( drupal_get_destination() == 'destination=logout' ) {
header( 'Location: <a href="http://'" title="http://'" rel="nofollow">http://'</a> . $_SERVER['HTTP_HOST'] . '/' ) ;
exit;
}
?>
at the top. If I remember right, it completely disabled the dialog on log-out, but that was ok for my site, because I have no users that log in through HTTP-AUTH. I used Securesite only for guarding feeds.
#16
The problem happens at logout because in securesite_user(), we call securesite_user_auth(). We might be able to check the destination to see if it's in the whitelist before doing so, but I'm not sure that would work.
#17
There is already a module to do what salvis wants: HTTP Authentication. The only problem we are having is that users stay on the logout page when they cancel the authentication dialog.
#18
I know about HTTP Authentication and it works for my purposes, too, but with one marked difference: if users fail to correctly configure their RSS reader, then you keep getting watchdog 'access denied' messages with HTTP Authentication, but with Secure Site you don't. That makes Secure Site preferable.
Why can't Secure Site remember whether it logged the user in or not?
#19
http://drupal.org/node/261961 was marked a duplicate of this issue. Basically, I am having the same problem as salvis (the bug submitter) one and a half years ago. My workaround for now was just to remove the auth call from the logout. It has no documentation on why it is there. This is obviously not a serious patch to work with, it is just a proof that this is in error. With the patch applied, logout works fine without the auth popup.
#20
See http://tools.ietf.org/html/rfc2616#section-15.6 for the reason we did this.
#21
Why not check for the existence of PHP_AUTH_USER then? If it is not there, there was no auth info, so there is no reason to try to trick the browser not to retain it.
#22
The current implementation is correct as only when HTTP Auth is used will the dialog be shown on logout to clear the auth variables.
The problem comes in when sites have more than one login point (e.g. login block on unprotected pages). This is not something I have ever noticed before or thought of so I think Gábor Hojtsy suggestion is reasonable.
This is untested but this is way I see it.
If HTTP AUTH is used and the user auth variable is set and not empty then display the dialog. I don’t think we need to worry about the password variable. I can’t think of a way of logging in without a username regardless if the password is set or not.
<?php$securesite_enabled = variable_get('securesite_enabled', SECURESITE_DISABLED);
if (($securesite_enabled == SECURESITE_AUTH || $securesite_enabled == SECURESITE_AUTH_ALT) && !empty($_SERVER['PHP_AUTH_USER'])) {
securesite_user_auth();
}
else {
// redirect first to browser prevent caching problems
securesite_goto();
}
?>
To prevent future confusion I also think this should be documented, regardless if we change the logout or not.
#23
NaX: Great, does this work for you as well? Patch attached to get this going sooner then later.
#24
@NaX: I'm afraid your patch does not solve the problem entirely. I'm not sure why, but on my site the HTTP authentication dialog is not shown again when I log out after logging in with HTTP auth. (tested in IE and firefox).
#11 uses a session variable that can be used to track what login method was used by the logged user. In case the user logged in with HTTP authentication, the 401 header is set again when the user logs out. If the user logged in using some other method, the 401 header is not set. I implemented this in a patch relative to 5.x-1.2.
The patch also features an option to refer users to an 'Access denied' page instead of the reset password page, if they press the 'Cancel' button after logout in the HTTP authentication dialog. Furthermore, the firefox browser is included in the browser logout work-around.
#25
I've just checked in some initial unit tests for Secure Site. I will try to write some tests relevant to this issue within the next two weeks, then find the best solution and resolve this issue before releasing Secure Site 5.x-1.3 and finishing the 6.x port.
#26
@leop: Why did you include Firefox in the browser logout work-around list?
#27
Fixed on the DRUPAL-5 branch. I used leop's suggested solution (marking the session).
#28
I'll continue adding tests and release 5.x-1.3 when I'm comfortable that everything is working correctly, hopefully within the next two weeks. Test contributions are welcome. After 5.x-1.3 is released, I'll finish the 6.x port.
#29
Junyor and all - good work... nice to see this finally applied, tested and getting ported :)
Djun
#30
Automatically closed -- issue fixed for two weeks with no activity.