From: Keith D. <ke...@du...> - 2006-01-22 14:19:49
|
Summary: Using the login_auth plugin, if I navigate away from squirrelmail=20 without properly signing out and then try to return to the page, I get=20 =93Unknown user or password incorrect=94. The same error then persists on= =20 trying to refresh or reload the page. The plugin works fine when first=20 logging in or if I correctly sign out before leaving squirrelmail. Details: The problem occurs when we try to create an imap connection in=20 src/redirect.php. The session variable =91user_is_logged_in=92 gets unset= ,=20 so we try to log the user in again. The hook =91login_before=92 is called= =20 but does not succeed in setting $login_username or $secretkey to=20 anything useful, because it can=92t get the relevant variables=20 $login_auth, $login_auth_pass and $login_auth_user from SQ_SESSION. I=92m= =20 guessing that the relevant session has been destroyed before this hook=20 is called. Present in squirrelmail 1.4.4 (the current Debian version) with PHP=20 4.3.10 on a standard Debian sarge install. Not tested against anything el= se. Fix (or at least workaround... there may well be a better way): I=92m not sure that the session is not being destroyed for a good reason,= =20 and I=92d sooner change the plugin than the workings of squirrelmail. So,= =20 we will make the assumption that if the login_auth plugin is loaded and=20 if PHP_AUTH_USER and PHP_AUTH_PASS are set, then we must surely want to=20 use them, and stop placing any reliance on the existence of a=20 squirrelmail session. function login_auth_login_before_do() { global $just_logged_in, $login_username, $secretkey; sqgetGlobalVar('PHP_AUTH_USER', $PHP_AUTH_USER, SQ_SERVER); sqgetGlobalVar('PHP_AUTH_PW', $PHP_AUTH_PW, SQ_SERVER); if (empty($PHP_AUTH_USER) || empty($PHP_AUTH_PW)) return; $login_username =3D $PHP_AUTH_USER; $secretkey =3D $PHP_AUTH_PW; $just_logged_in =3D 1; } Other thoughts: The use of HTTP authentication fundamentally breaks the Sign Out=20 function and we should not be telling users that they are successfully=20 signed out when clicking on Login will take them straight back in with=20 no further security checks. We should display an alternative signout=20 page when login_auth is used, telling users that they must close the=20 browser in order to log out. We might as well refrain from destroying=20 the session in this case too, so that if they hit the Back button they=20 get straight back in (which they would via the Login link anyway, so=20 it's no loss in security terms). An updated version with fixes for both is at=20 http://xenon.dunnett.org/login_auth2.1-1.4.x.tar.gz Comments welcome. Regards, Keith |
From: Paul L. <pa...@sq...> - 2008-06-21 01:11:21
|
Sorry for the late reply, and thank you for your contribution. I have some comments: > Summary: > > Using the login_auth plugin, if I navigate away from squirrelmail without > properly signing out and then try to return to the page, I get "Unknown user > or password incorrect". The same error then persists on trying to refresh or > reload the page. The plugin works fine when first logging in or if I > correctly sign out before leaving squirrelmail. > > Details: > > The problem occurs when we try to create an imap connection in > src/redirect.php. I fail to see why you would ever return to src/redirect.php unless you first returned to src/login.php, in which case the plugin will go to work again from the beginning and work the same as when you first brought up SM. I cannot reproduce this issue no matter what I try. Going back to any other page works as normal. Are you speaking of having gone off so long that the PHP session dies? Let me try that.... well I do get a "you need an account to access this page" error and a link to the login page, but clicking the link logs the user in automatically as before, which seems fine. The session having died is a natural process, and we do in fact need to go back through the login process to generate a new one. I suppose we could force that automatically in the case of login errors, although when the http user/pwd does not match the SM one, we'd be caught in a neverending loop, so I'm inclined to leave it as is. Suffice to say: I cannot see the problem you do and see no need for any fix. src/redirect.php is only ever accessed from the login page (and should normally never even appear in the browser history), in which case the plugin works as designed. > The session variable 'user_is_logged_in' gets unset, so we > try to log the user in again. The hook 'login_before' is called but does not > succeed in setting $login_username or $secretkey to anything useful, because > it can't get the relevant variables $login_auth, $login_auth_pass and > $login_auth_user from SQ_SESSION. I'm guessing that the relevant session has > been destroyed before this hook is called. > Present in squirrelmail 1.4.4 (the current Debian version) with PHP 4.3.10 > on a standard Debian sarge install. Not tested against anything else. > > Fix (or at least workaround... there may well be a better way): > > I'm not sure that the session is not being destroyed for a good reason, and > I'd sooner change the plugin than the workings of squirrelmail. So, we will > make the assumption that if the login_auth plugin is loaded and if > PHP_AUTH_USER and PHP_AUTH_PASS are set, then we must surely want to use > them, and stop placing any reliance on the existence of a squirrelmail > session. > > function login_auth_login_before_do() > > { > global $just_logged_in, $login_username, $secretkey; > sqgetGlobalVar('PHP_AUTH_USER', $PHP_AUTH_USER, SQ_SERVER); > sqgetGlobalVar('PHP_AUTH_PW', $PHP_AUTH_PW, SQ_SERVER); > if (empty($PHP_AUTH_USER) || empty($PHP_AUTH_PW)) > return; > $login_username = $PHP_AUTH_USER; > $secretkey = $PHP_AUTH_PW; > $just_logged_in = 1; > } > > Other thoughts: > > The use of HTTP authentication fundamentally breaks the Sign Out function > and we should not be telling users that they are successfully signed out > when clicking on Login will take them straight back in with no further > security checks. We should display an alternative signout page when > login_auth is used, telling users that they must close the browser in order > to log out. We might as well refrain from destroying the session in this > case too, so that if they hit the Back button they get straight back in > (which they would via the Login link anyway, so it's no loss in security > terms). I agree. I am adding code that overrides the $signout_page config var if there was nothing there already with a custom page that says so much. Thanks for pointing that out. > An updated version with fixes for both is at > http://xenon.dunnett.org/login_auth2.1-1.4.x.tar.gz Dead link > Comments welcome. > > Regards, > > Keith > |