CI Sessions

[eluser]MrCrooked[/eluser]
I'm new to CodeIgniter and I'm really liking it so far! :wow: Yesterday for the first time I ran into some troubles with the CI sessions. To be honest I haven't tried to understand the complete source of the session library yet, only parts. Let me explain my problem by an example:
I have a page with a Java applet which can set up a http connection and post some variables and an image. The posting itself works fine. What happens is that the applet takes it's own session and after I leave the applet page that session will generate a new one too. So if I start with no sessions in my database and I log in and go to the applet page everything is working fine and I have 1 session in my database. I can just leave the page and it uses the same session. But when I use the applet to POST, the applet gets it's own session and the applet page session isn't valid anymore. Does anyone know why this happens?

[eluser]Yash[/eluser]
its a mess for me. even I can't go inside your problem.

You should read how set and get a session key. When you set a key

Code:

<?php $this->session->set_userdata('key','value') ?>

get a key

Code:

<?php $this->session->userdata('key') ?>

now whenever you want to create new session just destroy old one. Session lib has those functs. check out user guide and read it carefully.

[eluser]MrCrooked[/eluser]
I don't think you understand my problem, I'll try to explain it better. When I visit my applet page with a browser and login. Then a record is created in the session database. But when I use the applet to do a POST request(it sets up it's own HTTP connection) then this connection will have it's own session record as well. When I return to my applet page in my browser and navigate away from the applet page to another page, it will create a new record in the session database, meaning I lost all my session userdata.

I also noticed the session library is purely based on cookies and when some visitor doesn't have them enabled then your sessions won't work. So i'm thinking to write my own hybrid native php sessions/cookies library. I also found some libraries on the wiki which almost meet my needs.

[eluser]pistolPete[/eluser]
Did you set

Code:

$config['sess_match_useragent'] = FALSE;

?

[eluser]MrCrooked[/eluser]
Yes, I tried both options, the problem remains. Maybe someone can explain to me when a session will be lost/invalid?

[eluser]Unknown[/eluser]
I came across this problem I think you are right... the browser has a different user agent.

I fiddled with session.php log messages and saw that the reason the session cookie was being destroyed is because

"The user agent criteria for sessions was not met so the session has been destroyed!
DEBUG - 2009-12-26 12:03:28 --> because Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv does not equal Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_16"

The two user agents do not match. The latter agent is the java applet and the former is the browser (as it was the browser that logged in thus creating the session cookie in the first place).

However funny thing is actually this code is only supposed to be broken into when sess_match_useragent = TRUE, as it happens I changed mine to FALSE so I'm still investigating why sess_match_useragent = TRUE instead of FALSE by the time it gets to checking them.

I decided to run a test by outputting the values that are copied into the session variables from the config array in session.php:

The log code I did was:
foreach (array('sess_encrypt_cookie', 'sess_use_database', 'sess_table_name', 'sess_expiration', 'sess_match_ip', 'sess_match_useragent', 'sess_cookie_name', 'cookie_path', 'cookie_domain', 'sess_time_to_update', 'time_reference', 'cookie_prefix', 'encryption_key') as $key)
{
$this->$key = (isset($params[$key])) ? $params[$key] : $this->CI->config->item($key);
log_message('debug', "$key = ".$this->CI->config->item($key));
}

I got:
sess_encrypt_cookie = 1
DEBUG - 2009-12-26 12:17:42 --> sess_use_database = 1
DEBUG - 2009-12-26 12:17:42 --> sess_table_name = ci_sessions
DEBUG - 2009-12-26 12:17:42 --> sess_expiration = 7200
DEBUG - 2009-12-26 12:17:42 --> sess_match_ip = 1
DEBUG - 2009-12-26 12:17:42 --> sess_match_useragent = 1
DEBUG - 2009-12-26 12:17:42 --> sess_cookie_name = ci_session
DEBUG - 2009-12-26 12:17:42 --> cookie_path = /
DEBUG - 2009-12-26 12:17:42 --> cookie_domain =
DEBUG - 2009-12-26 12:17:42 --> sess_time_to_update = 300
DEBUG - 2009-12-26 12:17:42 --> time_reference = local
DEBUG - 2009-12-26 12:17:42 --> cookie_prefix =
DEBUG - 2009-12-26 12:17:42 --> encryption_key = hhi787g78gyugcdfde34w43w546e7fiy



However, my config values were actually
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 7200;
$config['sess_encrypt_cookie'] = TRUE;
$config['sess_use_database'] = TRUE;
$config['sess_table_name'] = 'ci_sessions';
$config['sess_match_ip'] = TRUE;
$config['sess_match_useragent'] = FALSE;
$config['sess_time_to_update'] = 300;

The useragent one does not match!
I have a vague idea that either I've done something silly or there is something up with $this->CI->config->item (fetching the wrong value).

Not sure what is going on completely but I think I have a lack of time so I just took out the call that checks for user agent and that fixed my problem with a dead session when I deploy a java applet that communicates with the server.

If I get around to seeing what's wrong I'll post on here, its not impossible I have done something wrong, can't thing what at the moment.

[eluser]BrianDHall[/eluser]
I use OB_Session library session available in the Wiki, and I have a similar situation where Flash POSTing gets it's own session, but the session doesn't get lost on the parent page. I have to use a bit of a hack to have my Flash submit a session key with its request so I can manually load the session during the reception of the POST so it has the same session information available to the page itself.

So I think that would work with your Java example - you might try it since its just a drop-in replacement, you don't even over-write your core session file. If it doesn't work then delete it