banned user can't log out

[plb]

I'm not sure how big a deal this is outside of a development environment. I think I could come up with a use case where the functionality would need to be there, but I may be stretching it.

Anyway, user X gets banned (users->permissions = 0). Now user X logs in.

Roach motel - you can check in but you can't check out. There's no way (without going behind the scenes and editing the session or etc.) that user X can now log out.

[plb]

Recommendation: around line 373 of us_helpers.php where you have this code:

if(isset($user) && $user->data() != null){
if($user->data()->permissions==0){
bold('<br><br><br>Sorry. You have been banned. If you feel this is an error, please contact the administrator.');
die();
}
}

Instead of printing a message and dying, (1) log that user out and (2) redirect them to the login screen with a message:

Redirect::to($us_url_root.'users/login.php?err=Sorry. You have been banned. If you feel this is an error, please contact the administrator.');

Of course, login.php has to be modified to accept a $_REQUEST['err'] and appropriately display it.

[firestorm]

you could display the message then redirect with a short delay to the login form

[plb]

Any advantage of the delayed message followed by a "clean" login form as opposed to redirecting directly to the login form with a message displayed above the login? The latter takes about 12 seconds to implement and allows the user to read the message even if they aren't looking at the screen at the exact moment that the message appears and disappears...

[plb]

Here's a link to a modified login.php

http://pastebin.com/FSLFYwaW

I've added a single line immediately after the

Code:

$error_message='';

initialization.

Code:

if (@$_REQUEST['err']) $error_message = $_REQUEST['err']; // allow redirects to display a message

Now any

Code:

Redirect::to('users/login.php?err=This is an error message');

will display that message in the login form.

[plb]

Here's the link to the changes needed in us_helper.php

http://pastebin.com/X4mK8uG3

(just changed the bold() and the die() lines around 375 to a single Redirect::to())

[plb]

Sorry - changes above to us_helper.php are not yet complete... It errors out if called from somewhere in another directory (like from one of the users/*.php scripts.

I'm working on a mod to classes/Redirect.php to fix this problem (same problem I found somewhere else on these forums...)

Stay tuned...

[plb]

OK, changes done. See here for Redirect.php

http://pastebin.com/yvSx71U1

These changes are as follows:
(1) allow arguments as an optional second argument:

Code:

Redirect::to('login.php', '?err=Error+Message');

(2) Fix problems with relative paths where sometimes the redirect is to users/script.php and other times it is to script.php and if you are not already set in the users directory it can cause problems
(3) clean up some tabbing so code aligns better and is more readable

I *believe* that with all 3 of these changes (Redirect.php, us_helpers.php, and login.php) the original bug is fixed along with the problem with the relative paths in Redirect.

Do note that in the long term it would be better if all Redirects use $us_url_root.'path/to/script.php' instead of just 'to/script.php'. This would remove the ambiguity that my fix is trying to solve...

[mudmin]

The leaving them logged in was actually intentional. My thought was if they did something to be banned, why make it easy to log back in.

I can definitely implement this stuff. And yeah...you're definitely right about the path stuff. That whole thing that auto detects root was new in 4.1.0 so it may not have been fully implemented properly in every situation.

Bottom line is you're right. Your solution is much better than my hack job.

[brian]

I think the best action would be to leave the redirect class without the $us_url_root variable, since that can always be added when the redirect is called, and leaves the Redirect class more general while still being able to achieve that functionality.

I like the idea of the Redirect argument, and have already done something similar with the email function to enable supporting other forms of mail.