Possible bug

[eluser]preams[/eluser]
Hello guys

This is my first post, I usally search the maximum I can before I ask something, that's why I'm only getting active now, though I come here for a while.

I started to get http 403 error in a client's website where I used CI 2.1. It was strange because I didn't really do any change to the code. After digging I found that this only happens in WebKit browsers ( I tested in Safari, iOS and Chrome, all of them the latest release ) and from that I thought that it must be something related to the USER_AGENT variable. Well turns out that CI 2.1 crops this variable from 0 to 120 chars while in these WebKit browsers it's length is 125 ( in iPad's at least, in the others I havent really tested after I found the workaround ).

I tried to change in the DB and in the Session library the maximum length to 255, but that doesnt solve the problem, it keeps generating a corrupted cookie... The USER_AGENT in iPad with latest iOS is:

Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3

Maybe some character is corrupting the cookie? Don't know...

Well the workaround for now is to turn on cookie encryptation in the config file. Not a problem, but now I'm curious on why it generates a corrupted cookie without encryptation.


Maybe you guys can help me with this.

[eluser]InsiteFX[/eluser]
If you think that is bad look at the length of some of IE's User Agent strings well over 255 chars...

[eluser]arkin[/eluser]
I had the same issue a few weeks ago with an install.

The solution I used was to increase the limit on the VARCHAR field for the `user_agent` field in `ci_sessions`. VARCHAR has a limit of 3000 chars (before you need to consider a different data type), I think I only increased mine to 300.

I have been meaning to suggest for a while that CI hashes the user agent to md5 (CHAR 32) but I guess people like seeing user agents in their sessions table.

[eluser]preams[/eluser]
Well InsiteFX I didn't know that about IE, thanks.

arkin, I tried to increase mine but didn't work, but I'm with you about creating a user agent hash, no need to store that much data, or at least, create a field to store the hash and use that to compare and leave the actual user agent field for those who like to read it for debug purposes...

I still have the problem AFTER using encryptation sometimes, it's like a random thing now but people reported to me that it still happens sometimes in various browsers.

Now I'm trying a different solution. I'm encoding (urlencode) the cookie data on setcookie function and it seems to be working for now, for both encrypted and not encrypted cookies...

I'll see if that works for the rest of the day anyway

[eluser]InsiteFX[/eluser]
@arkin, you can increase the size all you want but CodeIgniter has it set internally to 120!

[eluser]CroNiX[/eluser]
Yes, you'd also have to change some things in the actual session class if you want to use a different value. Changing the length in the session database table is only part of the solution. Changing the value has been proposed on github but Phil basically said it shouldn't matter so they don't want to increase it.

Here is a discussion on the issue from GitHub:
https://github.com/EllisLab/CodeIgniter/issues/1090

[eluser]preams[/eluser]
@CroNiX I personally believe that it doesn't metter too, because I've changed it in the Session class and sessions table and the problem persisted. And it makes sense since when Session class store and compare that value, it's always cropped to that fix value so for comparison it's the same

[eluser]arkin[/eluser]
IF they want to keep it at 120, they should at least make sure to trip the user agent string to 120 chars to avoid this problem happening. I have had it too, but, maybe it is fixed in dev?

EDIT: My bad. The code is in there to limit it, so this is fixed (in github version) with 'user_agent' => substr($this->CI->input->user_agent(), 0, 120)

[eluser]CroNiX[/eluser]
Yes, but it also allows for a higher probability that user agents will be the same for different people if only using the first x chars for comparison instead of the whole thing, allowing session collisions and accessing others session data (in the code, not directly). Since some users use proxy servers or their ISP changes their IP routinely (sometimes on each request), you can't really rely on the IP for session management.

[eluser]preams[/eluser]
Well the error persists! The solutions I tried made it more rare but it still there

Can't think of other solution really, I will have to test on another server