Forums
This topic is locked
Losing session variable / id
Posted 26 Oct 2001 15:01:46
1
has voted
26 Oct 2001 15:01:46 Michael O'Neill posted:
I posted a problem with ssl a couple of days ago that I have found the cause of. When I am logged in and transfer to my secure site which is on a different domain I lose my session id or session variable $KT_Username and am redirected to my access denied, please login page.
From here I am totally baffled.
How do I fix this??
Any help appreciated.
Thanks
Mike.
Replies
Replied 26 Oct 2001 22:31:06
26 Oct 2001 22:31:06 andy dick replied:
If it is your server you probably need to have them login under the ssl domain, otherwise you will need to pass some information via a form field or query string to the SSL server.
-Andy
-Andy
Replied 27 Oct 2001 12:50:12
27 Oct 2001 12:50:12 Bruno Mairlot replied:
This is due to Cookie.
Session are stored in cookies (when you don't use it in an url). And cookies are domain dependant.
Don't forget that their are designed to be available only to the site that created them.
You can use the domain statement when defining the cookie, but, it won't work if you use the usual way of handling session in PHP.
What you can do is to get all variables you have in your session (like KT_Username) and send them in the URL when going to your secure site. And you might consider adding a small md5 sum, based on a small secret key to make sure none can spoof the session variable.
Then on the secure site, you will recreate a new session, constructed with every input received in the URL, and verifying the info correspond by recalcuting the md5 sum with the same key, on the secure site, and validate it or not.
There might be some other way to do that, but I don't know about them, though, I know that this one works.
--- Better to die trying, than never try at all ---
Session are stored in cookies (when you don't use it in an url). And cookies are domain dependant.
Don't forget that their are designed to be available only to the site that created them.
You can use the domain statement when defining the cookie, but, it won't work if you use the usual way of handling session in PHP.
What you can do is to get all variables you have in your session (like KT_Username) and send them in the URL when going to your secure site. And you might consider adding a small md5 sum, based on a small secret key to make sure none can spoof the session variable.
Then on the secure site, you will recreate a new session, constructed with every input received in the URL, and verifying the info correspond by recalcuting the md5 sum with the same key, on the secure site, and validate it or not.
There might be some other way to do that, but I don't know about them, though, I know that this one works.
--- Better to die trying, than never try at all ---
Replied 27 Oct 2001 15:04:14
27 Oct 2001 15:04:14 Michael O'Neill replied:
Thanks for the response, this is driving me mad.
I have tried passing the following variables to the secure page with no luck. I am probably doing something stupid.
$KT_UserAuthorization
$KT_Username
I have also tries passing the original PHPSESSID to the secure page.
It has also been suggested to append the url with <?=SID?> this does not work either!
Any help appreciated.
Mike.
Edited by - carphone on 10/27/2001 17:51:37
I have tried passing the following variables to the secure page with no luck. I am probably doing something stupid.
$KT_UserAuthorization
$KT_Username
I have also tries passing the original PHPSESSID to the secure page.
It has also been suggested to append the url with <?=SID?> this does not work either!
Any help appreciated.
Mike.
Edited by - carphone on 10/27/2001 17:51:37
Replied 27 Oct 2001 18:59:20
27 Oct 2001 18:59:20 Bruno Mairlot replied:
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
Thanks for the response, this is driving me mad.
I have tried passing the following variables to the secure page with no luck. I am probably doing something stupid.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
No ! Passing session values across different server, is something not easy at all !
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
I have also tries passing the original PHPSESSID to the secure page.
It has also been suggested to append the url with <?=SID?> this does not work either!
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
It is normal that it doesn't. It behaves the way it has been designed to.
In PHP a session ID is usually stored in a Cookie. The $SID var is here if the browser doesn't accept cookies.
But, session ID are stored in the temporary directory PHP uses. SessionID are also identified by the PHP process of being valid or not.
When you tell your secure PHP server to use the SID, it doesn't recognize it, because it comes from another server. In fact, it doesn't know anything about this particular session.
In my knowledge, you would have two possibility : store the variables in a database and fetch them on the secure server. But this isn't secure.
The second way is the pass the var $KT_UserAuthorization and $KT_Username in the URL.
When you're redirecting to the secure server, do you use a POST or a GET method ?
Suppose we are going to the secure page with a GET. You'll have in the URL the param : <b>...../myfile.php?KT_UserAuthorisation=1&KT_Username=bruno</b>
With this, the page myfile.php can use KT_UserAuthorisation and KT_Username in order to reconstruct the session on that particular server.
This should work. I suggest you to try this, and if it works, then secure the whole thing.
To secure it, create your own key. This might be a simple string like
<pre id=code><font face=courier size=2 id=code>$PrivateKey="The Lord of The Rings";</font id=code></pre id=code>
Then, you will create a one string that will contains the concatenation of $KT_Authorization,$KT_Username and $PrivateKey, and make an md5 hash of it with :
<pre id=code><font face=courier size=2 id=code>
$hash=md5($KT_Authorization.$KT_Username.$PrivateKey);
</font id=code></pre id=code>
Then you pass it in the URL too. <font size=1>Note that the $hash will always be of 32 character.</font id=size1>
On your secure server, at the beginning of the page, check that $HTTP_GET_VARS["hash"] is equal to the new generated hash string :
<pre id=code><font face=courier size=2 id=code>
$newhash=md5($HTTP_GET_VARS["KT_Authorization"].$HTTP_GET_VARS["KT_Username"].$Privatekey);
if($newhash!=$HTTP_GET_VARS["hash"]){
// The URL is a faked one !!
// Log the IP adress !
header("Location: /wrongurl.php"
}
else{
// reconstruct the session here !!
...
...
...
</font id=code></pre id=code>
--- Better to die trying, than never try at all ---
Thanks for the response, this is driving me mad.
I have tried passing the following variables to the secure page with no luck. I am probably doing something stupid.
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
No ! Passing session values across different server, is something not easy at all !
<BLOCKQUOTE id=quote><font size=1 face="Verdana, Arial, Helvetica" id=quote>quote:<hr height=1 noshade id=quote>
I have also tries passing the original PHPSESSID to the secure page.
It has also been suggested to append the url with <?=SID?> this does not work either!
<hr height=1 noshade id=quote></BLOCKQUOTE id=quote></font id=quote><font face="Verdana, Arial, Helvetica" size=2 id=quote>
It is normal that it doesn't. It behaves the way it has been designed to.
In PHP a session ID is usually stored in a Cookie. The $SID var is here if the browser doesn't accept cookies.
But, session ID are stored in the temporary directory PHP uses. SessionID are also identified by the PHP process of being valid or not.
When you tell your secure PHP server to use the SID, it doesn't recognize it, because it comes from another server. In fact, it doesn't know anything about this particular session.
In my knowledge, you would have two possibility : store the variables in a database and fetch them on the secure server. But this isn't secure.
The second way is the pass the var $KT_UserAuthorization and $KT_Username in the URL.
When you're redirecting to the secure server, do you use a POST or a GET method ?
Suppose we are going to the secure page with a GET. You'll have in the URL the param : <b>...../myfile.php?KT_UserAuthorisation=1&KT_Username=bruno</b>
With this, the page myfile.php can use KT_UserAuthorisation and KT_Username in order to reconstruct the session on that particular server.
This should work. I suggest you to try this, and if it works, then secure the whole thing.
To secure it, create your own key. This might be a simple string like
<pre id=code><font face=courier size=2 id=code>$PrivateKey="The Lord of The Rings";</font id=code></pre id=code>
Then, you will create a one string that will contains the concatenation of $KT_Authorization,$KT_Username and $PrivateKey, and make an md5 hash of it with :
<pre id=code><font face=courier size=2 id=code>
$hash=md5($KT_Authorization.$KT_Username.$PrivateKey);
</font id=code></pre id=code>
Then you pass it in the URL too. <font size=1>Note that the $hash will always be of 32 character.</font id=size1>
On your secure server, at the beginning of the page, check that $HTTP_GET_VARS["hash"] is equal to the new generated hash string :
<pre id=code><font face=courier size=2 id=code>
$newhash=md5($HTTP_GET_VARS["KT_Authorization"].$HTTP_GET_VARS["KT_Username"].$Privatekey);
if($newhash!=$HTTP_GET_VARS["hash"]){
// The URL is a faked one !!
// Log the IP adress !
header("Location: /wrongurl.php"
}
else{
// reconstruct the session here !!
...
...
...
</font id=code></pre id=code>
--- Better to die trying, than never try at all ---
Replied 28 Oct 2001 08:31:52
28 Oct 2001 08:31:52 Michael O'Neill replied:
Much appreciated.
Mike.
Mike.