Tank Auth and IE7 - login gives me a 404 error

[eluser]imcl[/eluser]
I've read on the forum re the issues surrounding CI sessions on IE7. There seems to be some consensus that changing

Code:

$config['sess_cookie_name']        = 'ci_session';

to

Code:

$config['sess_cookie_name']        = 'cisession';

and increasing to

Code:

$config['sess_expiration']        = 720000;

solves the issue. Not in my case.

I am using Tank_Auth as my authentication and when I try to login using IE7 or IE8 under compatibility view, it redirects me to a 404 error page.

This is pretty bizarre considering that the exact same login, without any modification, works well on IE8 and FF, Cr, and Safari.

Does anyone have any idea how to resolve this?

Any pointers are much appreciated. I am using CI 2.0.

[eluser]cmgmyr[/eluser]
Yeah, compatibility mode in IE does some pretty strange things. I was having a similar problem with this and switching between SSL and non-SSL. The site kept on making new sessions all over the place. I found out that compatibility mode seems to keep switching to different user agents. You can see this happening when you keep on checking the records in the session table.

The way that I battled this is to add:

Code:

<meta http-equiv="X-UA-Compatible" content="IE=8" />

to the header of my main html template. This forces that compatibility button to go away and the user is stuck in regular IE8 mode. There are other modes that you can use too, but this one seemed to work the best.

Hope that helps.

[eluser]imcl[/eluser]
thanks for the response --

On another site I've been doing what you recommended, via htaccess

Code:

###########################################
## Use this to force no-compat view on IE8

Header set X-UA-Compatible "IE=EmulateIE8"

Now -- what will happen if I implement this change you suggested and someone visits using IE7?

If the user is stuck in IE8 mode, how will my pages behave in IE7?

[eluser]cmgmyr[/eluser]
From my understanding, this "hack" is only for IE8 and above (with compatibility mode enabled). If you are just using regular IE7, then it will act like IE7, and you won't have the same session issues.

[eluser]imcl[/eluser]
I found a computer here at home with IE7 on it, so i can answer my own question --

obviously, the browser being IE7 it ignores the IE8 http-equiv instruction and Tank Auth login does not work.

so the solution above is not usable.

anyone have other ideas?

[eluser]imcl[/eluser]
Sorry for the bump -- but I haven't solved this issue with IE7 yet.

Does anyone have a suggestion of what may be going on or how to trouble shoot this?

When I try to login on IE7, it takes me to a 404 error at

Code:

http://mysite.com/auth/index.html

Is this an issue with Tank_Auth?

[eluser]InsiteFX[/eluser]
Final Solution

The timezone issue did give me a hint to check the time on my client and server. My client is a Windows laptop which had the correct time and timezone thanks to being synchronized with the NTP protocol. My server on the other hand was out of sync.

The timezone was correct, but the UTC time was set to my local time instead. As a result, the server was actually six hours in the past as far as the client was concerned. A timeout of one hour would have expired in the past for an IE instance running on my client. No wonder IE was rejecting my sessions.

I ran ntpdate to fix my time and then reset my timezone using tzselect.


# ntpdate pool.ntp.org
# tzselect

I then refreshed IE which immediately started accepting the sessions. All aspects of my application started working correctly. So much for so little.

Moral of the story, use NTP to ensure that your machines have their time set correctly.

change the IE setting as below:

tools Internet Options Privacy Advance Always allow session cookies.

And do not use an underscore in the cookie name or domain name!!!!

You can also search the forums this has been asked 100's of times...

InsiteFX

[eluser]imcl[/eluser]
thanks InsiteFX -- is your solution specifically for a server you own (ie, self -hosted website)?

My website is hosted in a shared environment (commercial webhosting) -- although I do have SSH access, I wonder if the change you propose can be done in my case.

Any idea?

UPDATE:

nevermind -- I just checked my server and client date/time and they match perfectly. so I think your solution doesn't apply to my case.