Re^2: Cookie->fetch problem

First let me get htis out of the way:

sub SetUserSessionCookie
{    
    my ($sname,$sid) = @_;
    #use CGI qw/:standard/;
    #use CGI::Cookie;
    my $sessioncookie = new CGI::Cookie(-name=>$sname,-value=>$sid,-ex
+pires=>$session_cookie_timeout,-path=>'/cgi-bin',-domain=>$domain,-se
+cure=>1);
    print header(-Cookie=>[$sessioncookie],-type=>"text/html");
}
[download]

The cookie is set anew each time I log in.

I will try to attach screen shot of firefox|options|cookies. Interestingly enough there is another unknown cookie that get posted to the page. Don't know where it comes from.Not in my code.

I will rake your advice and try to gin up something that will work. I have been fooling around with this all afternoon and it is very tiring. I usually (with advice) get issues resolved much faster.

Best regards

Comment on Re^2: Cookie->fetch problem Download Code

Replies are listed 'Best First'.
Re^3: Cookie->fetch problem by kennethk (Abbot) on Mar 09, 2017 at 22:41 UTC
Interestingly enough there is another unknown cookie that get posted to the page. Don't know where it comes from.Not in my code. Analytics software is often inserted at the server (e.g. Apache) level. My bet is that's the source. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply]
Re^3: Cookie->fetch problem by huck (Prior) on Mar 09, 2017 at 22:51 UTC
When you call SetUserSessionCookie what do you pass as $sname and $sid, if $sid is zero or $sname is not CGISESSID that may be where your problem is. Infact i forgot to suggest you check your mysql table for a sessionid of 0, and if you find it plain delete it. if you call `$session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh});` when $sid is zero and there is no sessionid 0 you will get a new sessionid back	[reply] [d/l]
Re^4: Cookie->fetch problem by tultalk (Monk) on Mar 09, 2017 at 23:27 UTC
Hi: It is setting the cookie with the session name as CGISESSID name and and the unique SID such as 08b6bf0fc7723abbc134fb0f1a09c5e8he SID generated with an MD5 hash using the username and password. This is done in the login iframe form and that hash is sent back to the server for verification. That sid is stored in the sessions table	[reply]
Re^5: Cookie->fetch problem by huck (Prior) on Mar 09, 2017 at 23:49 UTC
and the unique SID such as 08b6bf0fc7723abbc134fb0f1a09c5e8he SID generated with an MD5 hash using the username and password. This is done in the login iframe form and that hash is sent back to the server for verification. That sid is stored in the sessions table OH NO!!!!!!!!!! you are talking about that as an hidden input field of the login form. Lets see what happens if you call `$session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh});` with that "handmade" SID. it probably doesnt match a current session because CGI::Session uses some other method to compute its session ids, maybe even a md5 of the time+salt, so CGI::Session creates a new session and hands back ITS computed sessionid via `$session->id` that it uses internally. BUT you dont use that CGI::Session sessionid to set the cookie with, (which is used to call `new CGI::Session` the next time), instead you set the cookie to a value you (kinda) just made up it is fair to use your MD5 hash to check against a login table as a password, but that is not the sessionid CGI::Session wants to see. You need to set the cookie with $session->id instead so the next time thru CGI::Session can find the same session.	[reply] [d/l] [select]
Re^4: Cookie->fetch problem by tultalk (Monk) on Mar 09, 2017 at 23:57 UTC
Hi When the the page with the iframe is sent to the client, the call to get the cookies returns 0 if no cookies. That causes creation of a new session and the MD5 data being sent with the iframe response so a SID of 0 is just a flag. The call to set the cookie is: `#Set session cookie on client SetUserSessionCookie('CGISESSID', $sid);` [download] The SID being the MD5 hash of the username and password.	[reply] [d/l]
Re^5: Cookie->fetch problem by huck (Prior) on Mar 10, 2017 at 00:09 UTC
you need to understand what i said in Re^5: Cookie->fetch problem about how CGI::Session gives you back a new INTERNAL sessionid if it cant find the sessionid you give it or that session has expired. A SESSIONID IT COMPUTES ITSELF!!! http://search.cpan.org/~markstos/CGI-Session-4.48/lib/CGI/Session.pm If it fails, will create a new session id, which will be accessible through id() method. id() Returns effective ID for a session. Since effective ID and claimed ID can differ, valid session id should always be retrieved using this method.	[reply]
Re^3: Cookie->fetch problem by tultalk (Monk) on Mar 09, 2017 at 22:51 UTC
`my $dbh = ""; my $session = ''; my $sessionname = 'CGISESSID';` [download] is set at the beginning of the file and used all over including set and get cookies. I finally found where the expiration had been set at 1d and changed it to 7. The cookies are persistent. Checked before and after and against the sessions MySQL table. Best regards	[reply] [d/l]
Re^4: Cookie->fetch problem by huck (Prior) on Mar 09, 2017 at 23:12 UTC
another thing is that you may want to check your mysql sessions table to find any session-rows that have `_SESSION_ETIME > 604800` that would have been set as the result of that `Now()+72460*60` call. You may want to plain delete them and force those users to login again or reset them to 604800 ( 7 days)	[reply] [d/l] [select]