Not working properly: logged_in()

Question

Not working properly: logged_in()

Closed this issue 14 years ago · 12 comments

Thanks for porting this over to CI2, really looking forward to this working properly.

I've had to do a load of changes to make this work properly under CI2, which I will send as a pull request for you when I test them more.

I've run into a big problem that I can't fix, and need your input into it. Under the admin controller, there is a check being performed to see if a user is logged in, which currently always returns false, irrespective of whether the session is correctly set.

I am finding though that there are too many sessions being created, and only one of them has the correct details for this code, but it never seems to be the right one that is being checked.

Do you have any insight into this?

Answer 1 · 2011-08-24T17:41:08.000Z

There's a massive oversight on my part, I hadn't loaded the auth helper in the MY_Controller file. It should be fixed now, I'll leave this open just in case though.

Fixed in master branch.

Thanks.

Answer 2 · 2011-08-24T17:45:30.000Z

Cool, I have some changes to push to help this all out, I don't know but you've probably done it on a local branch.

Hope it helps though!

Answer 3 · 2011-08-24T18:22:25.000Z

Hi Adam, I've applied the fixes to my own, and I'm still getting odd behavior with sessions.

It seems that the first visit to the page (/login) creates a session. Logging in creates a new session. The redirect to the dashboard creates a new session. The dashboard check in the admin controller can't se the logged in session as the new one has taken over and therefore redirects to login again.

The single process is causing three sessions the first time, with the user details in the second one, and then two new ones per login attempt after that, the first always having the details.

I wonder what is causing this?

Answer 4 · 2011-08-24T18:43:35.000Z

This is extremely odd and I can't think why multiple session would be created. Are you using an extended session libraries?

Answer 5 · 2011-08-24T19:31:26.000Z

No, it' just pure CI2 ore and your auth files. Would it have anything to do with the config settings for cookies, csrf, xss etc?

Answer 6 · 2011-08-24T19:56:57.000Z

It shouldn't do. Since it's just the CI Session library. How are you checking to see that a different session is being created each time?

Answer 7 · 2011-08-24T19:58:34.000Z

I'm just looking directly in the DB for now.

Is it just the AG_Auth class that handles sessions?

Answer 8 · 2011-08-24T20:05:19.000Z

Yes just that file…in the login_user() function.

Answer 9 · 2011-08-24T21:50:20.000Z

I'm really confused here now.

I've dumped out data to screen to see what was what and I've definitely confirmed what I discovered earlier. The login page creates a cookie/session as default by CI, logging in creates another cookie/session and processes all the userdata, then when the redirect occurs back through the admin controller, another cookie/session is created. I really don't know what's happening here, and Googling around hasn't helped any either.

Answer 10 · 2011-08-24T21:51:52.000Z

It seems that the cookie/session's created by default CI are persistent, and remain continuously until I interact with the login, where the cookie is replaced and then replaced again by CI on redirect to a page that has no cookie/session interaction (apart from the login check, but by then the cookie has been replaced)

Answer 11 · 2011-08-24T22:11:27.000Z

That's extremely odd. I'll take a look at it tomorrow when I'm not so tired.

Answer 12 · 2011-08-25T08:10:50.000Z

Adam, don't worry about it now, the fix was to do with CI version > 2.02 needing alterations to the ci_sessions table.

CREATE INDEX last_activity_idx ON ci_sessions(last_activity); ALTER TABLE ci_sessions MODIFY user_agent VARCHAR(120);

I'll add this to the SQL today.

There are a couple more fixes to do with user management, but I'll work on that later.