I have a user management interface built from fosUserBundle, and sometimes I get logged out after opening a user, it does not matter if I edit anything on this user, and save the changes, or if I just bring up the edit user form and then hit the back link, I still get logged out without any error or warnings in app_dev.php mode.
...and I realized that is what symfony2 does when you bring up a form to edit the currently logged-in user. If I am logged in as admin, and open the edit form for this user, the next route I go to (doesn't matter which one it is) will take me to the login page, bringing up the edit form for the currently logged-in user will log me out, no error or warning.
Thought it might be helpful to someone else who doesn't know that you can't edit the currently logged-in user.
I think it would be great if symfony2 threw an exception telling you that this is the reason for auto logout, at least in dev mode.
First you should check your logs in Apache.
I had a similar issue and it was caused by duplicate column name in one of the entities. All the other entities refused to work and it ended in being logged out every time I clicked something in admin.
Related
I've got the error above in my Joomla website when I either try to log in or create a new account from the side site. I have also noticed the two following things:
if I create a new user from the backend, this doesn't appear in the _users table;
a file named ".myjoomla.configuration.php.md5", containing an alphanumeric string, is automatically generated in the website root every time I try to log in vainly from the frontend. Besides, it turns up again if I remove it manually through FTP.
Did my website get hacked? How could I fix it?
".myjoomla.configuration.php.md5" contains the md5 hash of the configuration.php file and appears on your site as part of the mySites.guru service you either subscribed to or trialled. It is part of the near-realtime alerting service which detects when configuration.php has been changed and alerts you if you are a paying subscriber of the mySites.guru service. It is NOT an indication of a hack at all.
Disclaimer: It is code I wrote and a service I run, so I know what Im talking about.
Not being able to create users - Im guessing you have Admin Tools or RSFirewall installed and configured, both these products stop users being created IF configured that way.
Token issues: These are well covered in Joomla documentation and forums. They are CSRF tokens and if yours is not validating then try NOT double clicking the buttons, check your session handlers are working, and check your cookies are working as expected
Nothing you say leads me to believe your site is hacked
The issue I've encountered was about the Joomla native Login module. As I published it in all the pages of my website and clicked on the login link appeared on the frontend side, I was redirected to a link that looked like
mysite.com/index.php/component/users/?view=login&Itemid=yourid
which displayed the login page correctly. Yet, once filled in the form and submitted it, the warning message in question popped out. The same problem occurred when either trying to register a new account or reset the password.
Although I couldn't find an explanation to the issue, I managed to fix it by creating a Login, Reset and Registration menu items under the main menu and then hidden them as I didn't want them to show up among the other menu items on the frontend.
Went back to the frontend and clicked on login, I was now redirected to a different url that looks like
mysite.com/login
where "login" is the alias that I had chosen for the Login menu item.
After having filled in the form and submitted it, I was able to log in successfully. Likewise, Registration and Reset operations worked.
This time I got a curious bug in my project managing the roles from a user.
I got installed the EasyAdmin bundle where I can manage the roles from the users. So I log with a user that have access to the EasyAdmin (ROLE_ADMIN in this case). Beside of this role I have also a few roles more, one of them, called ROLE_SUPERSUSER, where a user can edit 2 fields that the rest of users don't have the permission to edit them.
So throw the EasyAdmin, I remove the ROLE_SUPERSUSER from myself and here comes the gest of the matter. If I try to access to the edit zone from the profile if you have this ROLE_SUPERSUSER you will be able to edit this field, but because I removed it this role from myself, I expect to don't watch this fields over there. Instead of this, an error appears in the screen.
If I just logout and log in again the problem it's solved. But obviously I can't force the users to logout and login when I change their roles.
I guess the problem comes throw the cache but I don't find a solution.
Symfony roles are added on authentication by default, so you would have to re-login for this change to take effect.
You can change this in security.yml.
security:
always_authenticate_before_granting: true
I could find a solution thanks to KNPUniversity.
The solution pass throw the creation of a listener who updates the user before each controller.
I got the ideas from these links:
https://github.com/symfony/symfony/pull/24331
With special attention to this link:
https://github.com/symfony/symfony/issues/12025#issuecomment-219723819
I'm currently planning my web application. I was thinking using Session to store user profile (user name, current database, permissions, etc...). Common scenario is where user opens several tabs for different pages.
Now, I need to have an option for user to change the database. Basically needs to choose the database from list, enter a log in information and it's done. Not sure how to handle this. It seems that browser tab where user initiated the change should somehow tell server that he needs a new session here or server has to inform browser that new session is generated?
Basically if user has 4 tabs open and initiates a database change on one tab then he should end up with two sessions? Is this correct or is there a better way to handle this?
As far as I am getting your problem, one thing can be done that whenever the user selects a new database and enters the log-in information then on selecting the new database, you need to clear out the old session details for the database and on entering the new session for login information, override the login details.
Also, store the old information into another session and whenever a conflict occurs you can navigate to the error page saying that "Login information and databse have been changed" or any custom message.
Only work around needs to be thought of for this scenario as in same browser the session value will be same throughout.
Scenario: I have the membership provider setup and its currently pointing to a SQL database on my machine. The role based access works and I have a menu that is security trimmed. The user can only get to pages that they have access to.
Problem: When an anonymous user tries to get to a page that they dont have access to it brings them to a login page so that they can login. That is fine. But when a logged in user tries to get to a page they dont have access to(Usually by typing in a URL) it brings them to the login page again asking them to login(except there already logged in. I'd like to either take them to a different page or somehow tell them they don't have access. Any ideas/suggestions?
Thanks in advance
This is what I use. They point out that using <customErrors> won't work because of the way the 401 status gets changed and provide a solution.
When i hit back in the browser the user is still logged in. can someone help please?
I'm assuming mean:
"After the user logs out, if they then press back in the browser the page says they are still logged in. How do I stop this?"
If so, what the user is seeing is the browsers cached version of the page - they are not actually still logged in, and if they were to browse elsewhere, then they would see that they are now logged out.
I often get around this by having the LoginStatus control have a LogoutAction of Redirect, and the LogoutPageUrl set to something like the homepage.
That is the correct behaviour for most web applications. Being logged in is a question of state, and does not rely on the page you are viewing.
If you want the back button to log the user out, then it would seem that it is a case of whichever page the previous one was, is where you want logged in users to be automatically logged out. It might be the case that the previous page (accessed through the back option) is the login page, where you would want logged in users to automatically be logged out.
To get a more accurate and more helpful answer, you should specify what behaviour you are expecting, and include details about the authentication system you are using (for example ASP.NET membership).