Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

User gets "You need to be logged in to view this page" after succesful login (Trac #2677) #2677

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 7 comments
Closed

User gets "You need to be logged in to view this page" after succesful login (Trac #2677) #2677

elgg-gitbot opened this issue Feb 16, 2013 · 7 comments
Labels
engine worksforme

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/2677 on 40896361-08-10 by trac user coldtrick, assigned to unknown.

Elgg version: 1.7

After a succesful login some users got the gatekeeper message "You need to be logged in to view this page". So no wrong username or password.

After days of digging and logging this resulted in the following conclusion.

On some browsers (mostly IE8 in our case) the session cookie was too late (or not at all) updated on the client side. When arriving on the page (after a succesfull login) the session id of Elgg is not matching the session id in the cookie and therefore you are not logged in.

This behaviour is caused by the session_regenerate_id function in the login function. You can read about these issues in the comments on this function ([http://php.net/manual/en/function.session-regenerate-id.php]).

I don't consider this a bug as it prevents Session Fixation (http://en.wikipedia.org/wiki/Session_fixation). I just report this here so it may benefit others.

Our client decided to drop this extra security feature so all users had no issues logging in. There were extra security measures in place that should prevent unwanted site usage.

If you decided to disable this session_regenerate_id function in the elgg login function i strongly advice to add the following to your htaccess (or php.ini)

session.use_only_cookies = 1;

This also makes session fixation harder [http://www.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies]
@elgg-gitbot
Copy link
Author

cash wrote on 40897000-07-07

  1. You say mostly IE8. What other browsers exhibited this problem.
  2. Do you have server access logs for one of these cases? I'd like to see if the user agent is changing just to see if going into compatibility mode might be triggering this.
  3. Could you capture the traffic on the browser computer using a tool like Fiddler? If not, could you capture at least the request and server globals for the requests on the server?

@elgg-gitbot
Copy link
Author

trac user coldtrick wrote on 40897030-02-22

  1. we do not know for sure if only IE8 users are affected. We did not do extensive logging on browsers related to this issue. "Mostly IE8" is based on internet resources we found where other people experiencing the same issue report it as related to IE8.

  2. we ruled out fingerprint issues as we already disabled that.

  3. what would you like to find?

@elgg-gitbot
Copy link
Author

cash wrote on 40897196-09-12

  1. So are you saying that you have only seen IE8 users affected?

  2. Not concerned about fingerprinting - I want to know whether an IE8 session bug is triggered by going in and out of compatibility mode.

  3. I want to see the HTTP headers. I have seen IE send two session cookies before. It might be getting the new session cookie but sends both the new and old session cookie on the next request.

@elgg-gitbot
Copy link
Author

trac user coldtrick wrote on 40897223-07-28

Ok i will try to enable some logging to track down the issues.

I've seen the situation of IE8 and IE9 going in and out of compatibility mode, but could not relate it to this particular problem. As user_agent is not related to the session (other than the fingerprint) as far as i know.

All ideas still do not lead to a constructive solution for this "bug";

@elgg-gitbot
Copy link
Author

cash wrote on 41258311-09-06

Any more information on this?

@elgg-gitbot
Copy link
Author

cash wrote on 41400671-05-04

We're basically no where on this issue. We have had no reports outside of this ticket. We don't know what versions of IE are affected by this and it may not even be repeatable. Not sure what to do with this ticket.

@elgg-gitbot
Copy link
Author

brettp wrote on 41403531-05-18

Closing this one since there are no other reports. Sounds like an edge case, if not a fluke. Reopen if more problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
engine worksforme
Milestone
No milestone
Development

No branches or pull requests
1 participant
@elgg-gitbot