This object is in archive!
Session timeout causes exceptions
Using v2.3.11 and session expires the application does not redirect you to login. Instead you get an exception with access denied. Nice joke right? :)
Obviously it's not acceptable to get an exception when sessions expires.
Henrik,
This may cause on development environment (can be switched in root .htaccess file) or when "show_errors" is set to true in main config.
Additionally, when you run UseResponse on localhost (127.0.0.*) system will automatically switch "show_errors" directive to true.
In other cases all exceptions will be switched off for directly output, instead of this you'll be notified by email with Crash Report about any troubles during UseResponse using.
Access denied message will be shown when user without admin privileges tries to take admin control, so it's normal practice to stop such attempt with "Access denied" message.
Henrik,
This may cause on development environment (can be switched in root .htaccess file) or when "show_errors" is set to true in main config.
Additionally, when you run UseResponse on localhost (127.0.0.*) system will automatically switch "show_errors" directive to true.
In other cases all exceptions will be switched off for directly output, instead of this you'll be notified by email with Crash Report about any troubles during UseResponse using.
Access denied message will be shown when user without admin privileges tries to take admin control, so it's normal practice to stop such attempt with "Access denied" message.
Ok so far so good. After managing to disabling the dev-mode we see the errors in a more beautiful design.
However it doesn't change the fact that it's still wrong logic.
Standard practice is to redirect to let the user login again. Imagine if Google or Amazon would do such a trick like this. Instantly they would loose millions of users who would find it confusing why it says access denied.
Ok so far so good. After managing to disabling the dev-mode we see the errors in a more beautiful design.
However it doesn't change the fact that it's still wrong logic.
Standard practice is to redirect to let the user login again. Imagine if Google or Amazon would do such a trick like this. Instantly they would loose millions of users who would find it confusing why it says access denied.
Google practise is a bit different as they have backend pages only that can't be accessed without login. In our case it's different, as we provide access only to public data.
For example, you enter URL of the topic that is private. It will redirect you to login form, as user tried to reach it and he had a link to it.
On the other side... If you enter /admin url, and you are not logged in, it should redirect you to the login form, as you don't have permissions and it's only admins that can access it, so it's not a problem to login and go to Administration page, because you won't have that link anywhere in emails, but will reach it only by entering in browser.
Google practise is a bit different as they have backend pages only that can't be accessed without login. In our case it's different, as we provide access only to public data.
For example, you enter URL of the topic that is private. It will redirect you to login form, as user tried to reach it and he had a link to it.
On the other side... If you enter /admin url, and you are not logged in, it should redirect you to the login form, as you don't have permissions and it's only admins that can access it, so it's not a problem to login and go to Administration page, because you won't have that link anywhere in emails, but will reach it only by entering in browser.
Replies have been locked on this page!