Re: [PHP] sessions and trans-sid problem/question
Michael Sims wrote: I 'm not where I can test this right now, but if a session is older than session.gc_maxlifetime, isn't it invalid anyway? I.E. if I bookmark a page on your site and then come back 3 hours later passing an old SID, shouldn't that session have expired on the server by that time, in which case the session vars would be empty and you could kick me back to your login page? If my understanding of sessions is correct, no. session.gc_maxlifetime does set the lifetime of a session, but a session will not be cleaned by PHP until session.gc_probability has been hit. Again, if my understanding is correct, PHP doesn't automatically check to see if a session has expired before accessing it. It pre-supposes that any session file lying around is till active. And those session file will stay there until session.gc_probability has been hit. I might be wrong though ... Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Michael Sims wrote: Then I suppose it's just an added feature of the session handler I am using. Maybe the OP should give it a shot, as I use it and I definitely don't have a problem with expired sessions I'll think about writing my own session handler as it can be quite useful. However I need to evaluate the amount of extra disk read/writes it would add. Using a DB vs the file system does add some overhead ... Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 08:47 24.11.2002, Jean-Christian Imbeault said:
[snip]
Ernest E Vogelsinger wrote:
if ($_COOKIE[$_SESSION['cookie_name']] == $_SESSION['cookie_token']) {
Ok, please forgive my ignorance, but in PHP isn't $_COOKIES the same as
$_SESSION?. I thought it was if the user had cookies turned off (and
even if the user had cookies turned on come to think of it) ... If not
I'm in trouble.
I was always under the impression that $_SESSION vars were passed as
cookies ...
[snip]
No, that's a misunderstanding. Session var's are never passed to and from
the client, only the session _name_ is passed, either via a cookie
(PHPSESSIONID) or via trans-sid href encoding.
Session vars are kept server-side in session storage, which is (by default)
a file located in the directory where session.save_path is pointing to. The
default file name is sess_session-identifier. The client only transmits
the session identifier so the server is able to correlate a session to a
particular request.
What I did for this particular application was to extend the system with a
cookie that's programmatically sent, using a random cookie name and a
random cookie content. Thus I am able to distinguish between multiple
logical sessions using the same session identifier, a scenario that could
happen when a URL containing a trans-sid has been bookmarked or transfered,
or when the client had opened a new window within the same session and
continued in split mode.
Whatever the client passes to PHP as a cookie you can access in the
$_COOKIES array. Whatever PHP has stored in session storage can be accessed
in the $_SESSION array. They are quite different.
--
O Ernest E. Vogelsinger
(\)ICQ #13394035
^ http://www.vogelsinger.at/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 08:56 24.11.2002, Jean-Christian Imbeault said: [snip] session.gc_maxlifetime does set the lifetime of a session, but a session will not be cleaned by PHP until session.gc_probability has been hit. Again, if my understanding is correct, PHP doesn't automatically check to see if a session has expired before accessing it. It pre-supposes that any session file lying around is till active. And those session file will stay there until session.gc_probability has been hit. I might be wrong though ... [snip] You're quite right := -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Ernest E Vogelsinger wrote: No, that's a misunderstanding. Session var's are never passed to and from the client, only the session _name_ is passed, either via a cookie (PHPSESSIONID) or via trans-sid href encoding. Thanks for clearing that up! I hadn't realized that only the session name was passed around. I thought all the session data was too. This now hands me a dilemma ... I was building my site conservatively, i.e. assuming the user would have cookies turned off. And so I am making heavy use of session variables. *But* I had thought that if the user had cookies enabled then the variables would be saved as cookie information, hence saving my server a lot of disk reads and writes. Now you have shown me the err of my ways ... I have to consider rewriting my scripts so that if cookies *are* enabled the session information is sent has cookie data. Hum ... I hate re-writes Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
on 24/11/02 11:10 PM, Jean-Christian Imbeault ([EMAIL PROTECTED]) wrote: This now hands me a dilemma ... I was building my site conservatively, i.e. assuming the user would have cookies turned off. And so I am making heavy use of session variables. *But* I had thought that if the user had cookies enabled then the variables would be saved as cookie information, hence saving my server a lot of disk reads and writes. Now you have shown me the err of my ways ... I have to consider rewriting my scripts so that if cookies *are* enabled the session information is sent has cookie data. Hum ... I hate re-writes I'd leave it as is... this ensures that ALL users can use the site, because the session id can be passed around in either the URL or cookies... and enabling trans sid means you don't even have to worry about it... PHP will use cookies if possible, or else append it to the URLs. What sort of stuff are you storing in the session that your are worried about with too many writes? Justin French http://Indent.com.au Web Development Graphic Design -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Justin French wrote: What sort of stuff are you storing in the session that your are worried about with too many writes? Oh, this site is just your regular, run-of-the-mill, amazon.com copy. For each open session I store up to 20 variables. It's not a lot, but each access to a script means a disk read/write so they will eventually add up if there are enough users. Of course this problem goes away if you throw enough money at the hardware ... Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 13:10 24.11.2002, Jean-Christian Imbeault said: [snip] This now hands me a dilemma ... I was building my site conservatively, i.e. assuming the user would have cookies turned off. And so I am making heavy use of session variables. *But* I had thought that if the user had cookies enabled then the variables would be saved as cookie information, hence saving my server a lot of disk reads and writes. Now you have shown me the err of my ways ... I have to consider rewriting my scripts so that if cookies *are* enabled the session information is sent has cookie data. Hum ... I hate re-writes [snip] Why would you do that? session data is read and decoded once from a LOCAL file, while transmitting all session data over a REMOTE line would be much slower. Further it's MORE than insecure to hand possibly sensitive session data to the client where any bad guy might tamper with it and harm your application. Lastly cookies are limited to a certain size of data (I believe it's 1k but I don't know exactly). Use sessions as intended, it's a very well tested and very fast way to create a persistent state across multiple subsequent connections. If you don't like the file approach you can always invent your own session handling system, be it database-driven (which would be even slower), or some kind of session-server process that runs locally and gets contacted by the applications, or even some shared memory... choose your ways, but keep your data at the server's. -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 14:15 24.11.2002, Jean-Christian Imbeault said: [snip] Oh, this site is just your regular, run-of-the-mill, amazon.com copy. For each open session I store up to 20 variables. It's not a lot, but each access to a script means a disk read/write so they will eventually add up if there are enough users. Of course this problem goes away if you throw enough money at the hardware ... [snip] Assuming you're running a server operating system (either Linux, or other X, or even Win2K _server_) disk i/o gets already greatly reduced by the OS. Any server OS implements its own decent file i/o cache that leverages repeated disk i/o transparently. I wouldn't bother about that too much. What you should keep in mind that the OS needs enough memory to build up its decent cache. Which would mean that you plug in more memory banks the more users you have. If you suspect your server is slowing down because of disk i/o why not run a realtime performance log to see where bottlenecks are, and to act accordingly then? My experience shows that file session storage is the very last bottleneck that ever would occur; the database times add up much quicker than any session file i/o would ever be able to. -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
On Sun, 24 Nov 2002 17:01:21 +0900, you wrote: Michael Sims wrote: Then I suppose it's just an added feature of the session handler I am using. Maybe the OP should give it a shot, as I use it and I definitely don't have a problem with expired sessions I'll think about writing my own session handler as it can be quite useful. However I need to evaluate the amount of extra disk read/writes it would add. Using a DB vs the file system does add some overhead ... Experience has taught me that the additional overhead is negligible, especially if the database is running locally on the web server... Having a DB based session handler comes in very handy when you are troubleshooting a new session-based application. It's much easier to run queries against active sessions that to mess around with files, IMHO. Good luck... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
--- Jean-Christian Imbeault [EMAIL PROTECTED] wrote: This now hands me a dilemma ... I was building my site conservatively, i.e. assuming the user would have cookies turned off. And so I am making heavy use of session variables. *But* I had thought that if the user had cookies enabled then the variables would be saved as cookie information, hence saving my server a lot of disk reads and writes. Now you have shown me the err of my ways ... I have to consider rewriting my scripts so that if cookies *are* enabled the session information is sent has cookie data. There are two reasons why you should not consider such a rewrite: 1. performance 2. security You say you want to pass data as cookies to save your server the latency of disk access. Think about that for a moment, and you will see that it makes no sense. This is similar to making a decision to store all of your data on a remote FTP server rather than your local disk, thinking that this somehow saves you time. Regardless of how much bandwidth your network has and how slow your disk is, there is no way transmitting this data to/from the client across the Internet is going to be faster than local disk access. Floppy access is probably not even as slow as what you are considering. A more important reason to avoid the rewrite you are considering is security. A cookie is sent by the client. The client can be anyone using your site. What if the client is trying to circumvent your site's security in some way? Do you really want to trust everyone who visits to be honest? When you set a cookie, you are asking the client to send that cookie (value unchanged of course) in future requests. There is nothing aside from honesty that keeps a client from changing the cookie. Also, cookies are intended as a mechanism for maintaining state. This means that they are well-suited for helping you identify a client (the Web browser). Session management requires a little bit more, and this is where PHP sessions come into play. Cookies are a poor choice for session management (state management + maintaining client data), and this is what it seems like you are considering. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Ernest E Vogelsinger wrote:
if ($_COOKIE[$_SESSION['cookie_name']] == $_SESSION['cookie_token']) {
Ok, please forgive my ignorance, but in PHP isn't $_COOKIES the same as
$_SESSION?. I thought it was if the user had cookies turned off (and
even if the user had cookies turned on come to think of it) ... If not
I'm in trouble.
I was always under the impression that $_SESSION vars were passed as
cookies ...
Hc
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 08:02 22.11.2002, Jean-Christian Imbeault said: [snip] Is it because I am putting the SID in the URL? I haven't tested with cookies yet as I want to get my site working without cookies first. Definetely yes. The PHP session is (with the default setup) nuthing more than a hash that's used to construct a file name. So the session ID 0ee410a57762be937d6d277b4ff642c8 will render the filename /tmp/sess_0ee410a57762be937d6d277b4ff642c8 which will subsequently used by PHP as the session storage. Adding a logout feature will help people who are worried about security, because it can kill the cookies on the browser. I agree! The problem I have now is that a user can bookmark a page with the SID in the URL and then come back later and the session is still active ... the session should close when the browser is closed. You cannot really control if the user is logging out or not - I saw a solution once where they had a JavaScript for onUnload where they warned the user that the next time he should log out - I believe the actual action was to use the onUnload handler to redirect the browser to the logout screen. However this wouldn't work if the user has JavaScript switched off. What I usually do (I also have session cookies switched off) is to send the user a session cookie when he logs in. This way I can use cookieless sessions, but when it comes to sensitive areas I can be sure that bookmarking or giving away the SID wouldn't automatically transfer the login session... I have set session.auto_start = 1 so I would think that after closing the browser and going to the bookmarked paged a new session would be started, killing the SID passed in from the URL no? I always recomment NOT using session.auto_start. It effectively disables making objects session-persistent as any class file needed for the objects must be loaded BEFORE objects gets reconstructed. When the browser requests an URL with a SID you have no control if this stems from a link or from a bookmark (maybe you could go and analyze $_SERVER['HTTP_REFERER'], but not all browsers tranmit it. What you can do is to have a timestamp of the last access recorded in your session so you can always check against your own timeout requirements. Personally I believe it's a good thing not to enable automatic session cookies. Relying on a session cookie effectively disables having two browser windows open with the same application but running in different contexts, since both would transmit the same session cookie. -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Justin French wrote: PHP cannot possibly know when a user closes a window... PHP regularly cleans out the garbage of old abandoned sessions, but you cannot expect this instantly... True ... but the browser does. I think I would not have this problem using cookies since the cookie would expire after the browser is closed. The reason I am seeing this problem is that I am passing the SID in the URL and hence PHP does not know that the browser was closed. If you access that URL tomorrow, I doubt the session will STILL be valid... True. I guess I should set the gc to clean up sessions more often than it does now. Maybe 30 minutes ... You should do some reading up in the manual php.ini, making sure what session destroy means, what session.auto_start means, etc. I know what they mean. I got very confused until you pointed a very obvious thing out. It's passing the SID in the URL that is causing the problem and as you pointed out there is no work-around. I'll just have to live with the fact that by passing the SID in the URL the session will be alive until the session gc cleans up. Thanks, Jc PS If I got any of this wrong please let me know. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 08:56 22.11.2002, Justin French said: [snip] PHP cannot possibly know when a user closes a window... PHP regularly cleans out the garbage of old abandoned sessions, but you cannot expect this instantly... This is controlled by the session.gc_probability value in your INI file which is set to 1 by default. This means that every 100th access to any PHP script on your server will initiate the session garbage routine which might kill your outdated session file. Increasing this value will make this process more often, setting it to 100 will have PHP run the garbage collector every time a PHP script gets executed (you shouldn't do this - think in concurrency terms...) -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Ernest E Vogelsinger wrote: Definetely yes. After reading Justin's post I realized that. What I usually do (I also have session cookies switched off) is to send the user a session cookie when he logs in. This way I can use cookieless sessions, but when it comes to sensitive areas I can be sure that bookmarking or giving away the SID wouldn't automatically transfer the login session... I don't get what you mean here. Can you explain a bit more? Sounds like what I need but I don't understand. You say you have cookies switched off but send the user a cookie ... a contradiction. I always recomment NOT using session.auto_start. It effectively disables making objects session-persistent I didn't know that but it doesn't matter as I don't do OO in PHP. Being also a Java programmer I can't wrap my brain around how PHP does pseudo-OO. Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Ernest E Vogelsinger wrote: This is controlled by the session.gc_probability value in your INI file I know I can probably find this in the documentation somewhere but ... how do I set the expire time on a session? Increasing this value will make this process more often, setting it to 100 will have PHP run the garbage collector every time a PHP script gets executed (you shouldn't do this - think in concurrency terms...) Again, why would congruency be affected by the gc? If the session hasn't timed-out then the gc won't clean it up. If it has then it's ok to clean it up. I obviously am missing something has what you say seems to make sense but I can see it just yet :) Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
On Friday 22 November 2002 16:28, Jean-Christian Imbeault wrote: Ernest E Vogelsinger wrote: This is controlled by the session.gc_probability value in your INI file I know I can probably find this in the documentation somewhere but ... how do I set the expire time on a session? Increasing this value will make this process more often, setting it to 100 will have PHP run the garbage collector every time a PHP script gets executed (you shouldn't do this - think in concurrency terms...) Again, why would congruency be affected by the gc? If the session hasn't timed-out then the gc won't clean it up. If it has then it's ok to clean it up. I obviously am missing something has what you say seems to make sense but I can see it just yet :) If you set it 100, then _every_ request in which sessions are used, PHP has to go through all the session files (by default stored in /tmp) and check whether they have expired. If you have a busy server you could have thousands of session files. Checking thousands of files at each request is very time consuming. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* Traffic jam on the Information Superhighway. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Jason Wong wrote: If you set it 100, then _every_ request in which sessions are used, PHP has to go through all the session files (by default stored in /tmp) and check whether they have expired. If you have a busy server you could have thousands of session files. Checking thousands of files at each request is very time consuming. *That* I understand and agree with. What I was more interested in was the concurrency aspect. Why setting gc to 100 might cause problems with concurrency. Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 09:28 22.11.2002, Jean-Christian Imbeault said: [snip] This is controlled by the session.gc_probability value in your INI file I know I can probably find this in the documentation somewhere but ... how do I set the expire time on a session? The session.gc_probability value is an overall value that you cannot escape as to my knowledge. If you want a finer granularity you need to run this from within your application. For example, when a iser accesses your script, record the current timestamp in session storage. On the next access, compare the current timestamp with the recorded one and act accordingly. Increasing this value will make this process more often, setting it to 100 will have PHP run the garbage collector every time a PHP script gets executed (you shouldn't do this - think in concurrency terms...) Again, why would congruency be affected by the gc? If the session hasn't timed-out then the gc won't clean it up. If it has then it's ok to clean it up. I obviously am missing something has what you say seems to make sense but I can see it just yet :) If it hasn't timed out it won't be touched, that's clear - but _if_ it has timed out it's not guaranteed that the gc has already removed the session file. Note that there is no expiry check when the session storage is accessed by session_start(); only the gc process itself checks if it should remove the session file. In another message, Jean-Christian Imbeault said: [snip] *That* I understand and agree with. What I was more interested in was the concurrency aspect. Why setting gc to 100 might cause problems with concurrency. Setting this to 100 means that _any_ script access will start the gc. Which means that even on a moderately busy server a multitude of gc's will check the session files, possibly interfering with each other as one gc removes a file that's being checked by another gc. Might be painless (I haven't looked at the implementation); but I'd avoid this as far as I could :) -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 09:25 22.11.2002, Jean-Christian Imbeault said:
[snip]
What I usually do (I also have session cookies switched off) is to send the
user a session cookie when he logs in. This way I can use cookieless
sessions, but when it comes to sensitive areas I can be sure that
bookmarking or giving away the SID wouldn't automatically transfer the
login session...
I don't get what you mean here. Can you explain a bit more? Sounds like
what I need but I don't understand. You say you have cookies switched
off but send the user a cookie ... a contradiction.
My php.ini has session.use_cookies set to 0, so no (automatic) session
cookies get transmitted. Thie however doesn't stop me from programmatically
sending a cookie to the client...
So that's what I do, basically: I might be using a session for a lot of
stuff that's not related to user login; but when a user logs in this happens:
a) Create a unique cookie name and remember it:
$cookie_name = md5(date('YmdHis'));
$_SESSION['cookie_name'] = $cookie_name;
b) Create a random value for the cookie:
$cookie_token = rand();
$_SESSION['cookie_token'] = $cookie_token;
c) Transmit this cookie to the client (lifetime=session):
setcookie($cookie_name, $cookie_token);
From now on, the login-check tests for the random session cookie to match
the token:
if ($_COOKIE[$_SESSION['cookie_name']] == $_SESSION['cookie_token']) {
// valid cookie found, so generate a new value
$_SESSION['cookie_token'] = rand();
setcookie($_SESSION['cookie_name'], $_SESSION['cookie_token']);
}
else {
// no cookie set, or token doesn't match - take the appropriate action
}
This helps me to allow multiple sessions at the same client computer, since
every session has its own unique cookie. Giving away a link containing a
SID wouldn't harm security since you cannot pass or bookmark session cookies.
I always recomment NOT using session.auto_start. It effectively disables
making objects session-persistent
I didn't know that but it doesn't matter as I don't do OO in PHP. Being
also a Java programmer I can't wrap my brain around how PHP does pseudo-OO.
It's not pseudo-OO - it's some kind of back-to-the-roots OO :) You _do_
have (single) inheritance, you _do_ have class abstraction, you _do_ have
polymorphism (although you need to go a lot by hand), but you _don't_ have
protected and private storage.
You can always put an object into session storage, like this:
class A {
function A() {}
}
session_start();
if (!is_object($a))
$a = new A();
$_SESSION['a'] = $a;
This will give you the same object of class A anytime you access the page
with the same session. Note however that the session handler needs the
class definition to be able to reconstruct the saved object - only the
class name, and the instance data, gets stored in session data.
--
O Ernest E. Vogelsinger
(\)ICQ #13394035
^ http://www.vogelsinger.at/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 09:28 22.11.2002, Jean-Christian Imbeault said: [snip] This is controlled by the session.gc_probability value in your INI file I know I can probably find this in the documentation somewhere but ... Forgot to add this (sorry): http://www.php.net/manual/en/ref.session.php -- O Ernest E. Vogelsinger (\)ICQ #13394035 ^ http://www.vogelsinger.at/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
On Friday 22 November 2002 16:44, Jean-Christian Imbeault wrote: Jason Wong wrote: If you set it 100, then _every_ request in which sessions are used, PHP has to go through all the session files (by default stored in /tmp) and check whether they have expired. If you have a busy server you could have thousands of session files. Checking thousands of files at each request is very time consuming. *That* I understand and agree with. What I was more interested in was the concurrency aspect. Why setting gc to 100 might cause problems with concurrency. Well if you have a few requests per second, then each of those requests will want to check through your thousands of session files meaning you will have tens of thousands of disk accesses? -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* Never raise your hand to your children -- it leaves your midsection unprotected. -- Robert Orben */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
On Fri, 22 Nov 2002 14:57:23 +0900, you wrote: [...] 1- the user logs in 2- bookmarks the page 3- closes the browser 4- opens the browser 5- goes to the saved bookmark page He has access to the page. I.e. the session did not close/terminate when he closed his browser ... I 'm not where I can test this right now, but if a session is older than session.gc_maxlifetime, isn't it invalid anyway? I.E. if I bookmark a page on your site and then come back 3 hours later passing an old SID, shouldn't that session have expired on the server by that time, in which case the session vars would be empty and you could kick me back to your login page? I personally use a custom session handler (MySql based, which I got from www.phpbuilder.com) and I believe this is how my site behaves, but I'm not for certain. I'll try to test it out and see... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
At 15:08 22.11.2002, Michael Sims spoke out and said: [snip] I 'm not where I can test this right now, but if a session is older than session.gc_maxlifetime, isn't it invalid anyway? I.E. if I bookmark a page on your site and then come back 3 hours later passing an old SID, shouldn't that session have expired on the server by that time, in which case the session vars would be empty and you could kick me back to your login page? [snip] I don't think the session handler checks session expiry - only gc does. I haven't checked the PHP sources yet, but I found out that on my development server (where we definetely don't have a lot of traffic ;-) session files can persist over night, and the session is still available in the morning... only when the gc_probability is hit (i.e. at the 100th access), the file gets removed. At least with my PHP (4.2.2, RH 7.2). -- O Ernest E. Vogelsinger (\) ICQ #13394035 ^ http://www.vogelsinger.at/
Re: [PHP] sessions and trans-sid problem/question
Jean, This is a common challenge with a pretty easy solution. First, in case you are curious why the session can be reestablished, the bookmarked page likely has the session identifier in the query string. Thus, it is unnecessary for the browser to send a cookie, because it is sending the session identifier as a GET variable. This is what PHP is using to identify the client. It is a bad idea to depend on the timeout of a cookie or the session cleanup process to maintain a session timeout mechanism. Instead, you should keep a timestamp stored as a session variable that you use to make any time-based decisions for that session. For example: $_SESSION[last_access] = gmmktime(); To use this value to enforce a timeout, you would make a check similar to the following to make sure it hasn't been too long since the last access: $seconds_idle = gmmktime() - $_SESSION[last_access]; If the number of seconds they have been idle is too long for you, force them to reenter their password or even completely reauthenticate to continue. If the idle time is acceptable to you, reset the session variable to the current time. Chris --- Jean-Christian Imbeault [EMAIL PROTECTED] wrote: I've made a site in PHP and on some pages a user needs to log in first before gaining access to the page. (i.e. there is a log in page). Once the user has logged in I keep that fact in a session variable so that he doesn't need to log in again. However I have found out that if: 1- the user logs in 2- bookmarks the page 3- closes the browser 4- opens the browser 5- goes to the saved bookmark page He has access to the page. I.e. the session did not close/terminate when he closed his browser ... In Netscape 7 I have checked the stored cookie and it is set to expire at the end of the session (which is the default I think), so I don't understand why the PHP thinks the session is still opened ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
On Fri, 22 Nov 2002 15:08:31 +0100, you wrote: I don't think the session handler checks session expiry - only gc does. I haven't checked the PHP sources yet, but I found out that on my development server (where we definetely don't have a lot of traffic ;-) session files can persist over night, and the session is still available in the morning... only when the gc_probability is hit (i.e. at the 100th access), the file gets removed. At least with my PHP (4.2.2, RH 7.2). Then I suppose it's just an added feature of the session handler I am using. Maybe the OP should give it a shot, as I use it and I definitely don't have a problem with expired sessions being reactivated. That's not to say that you cannot pass a SID that was given to you the day before, but all of the data that was associated with it will be gone using this custom session handler, and it will effectively be a new session with the same name. I'm using the MySQL based session handler which is available here: http://www.phpbuilder.com/columns/ying2602.php3 FWIW... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] sessions and trans-sid problem/question
I've made a site in PHP and on some pages a user needs to log in first before gaining access to the page. (i.e. there is a log in page). Once the user has logged in I keep that fact in a session variable so that he doesn't need to log in again. However I have found out that if: 1- the user logs in 2- bookmarks the page 3- closes the browser 4- opens the browser 5- goes to the saved bookmark page He has access to the page. I.e. the session did not close/terminate when he closed his browser ... In Netscape 7 I have checked the stored cookie and it is set to expire at the end of the session (which is the default I think), so I don't understand why the PHP thinks the session is still opened ... Help! Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
on 22/11/02 4:57 PM, Jean-Christian Imbeault ([EMAIL PROTECTED]) wrote: I've made a site in PHP and on some pages a user needs to log in first before gaining access to the page. (i.e. there is a log in page). Once the user has logged in I keep that fact in a session variable so that he doesn't need to log in again. However I have found out that if: 1- the user logs in 2- bookmarks the page 3- closes the browser 4- opens the browser 5- goes to the saved bookmark page He has access to the page. I.e. the session did not close/terminate when he closed his browser ... I know that for IE Mac users (not sure about NN7) it's not until you QUIT the application that the session is terminated... this is because one application (IE or NN) may have multiple browser windows attached to it. I *think* you'll find something similar in Windows... perhaps when ALL open browser windows are closed and/or the browser app is QUIT, the session will end? Adding a logout feature will help people who are worried about security, because it can kill the cookies on the browser. Justin In Netscape 7 I have checked the stored cookie and it is set to expire at the end of the session (which is the default I think), so I don't understand why the PHP thinks the session is still opened ... Justin French http://Indent.com.au Web Developent Graphic Design -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
Justin French wrote: I know that for IE Mac users (not sure about NN7) it's not until you QUIT the application that the session is terminated... I *think* you'll find something similar in Windows... perhaps when ALL open browser windows are closed and/or the browser app is QUIT, the session will end? I exited all apps and restarted the browser. Didn't help. I also copy-pasted the URL (http://192.168.254.14/my_account.html?step=order_listPHPSESSID=b6f60469a3a67b677cf9c13e34b17072) from my Netscape 7 browser into an IE browser and the sessions was still valid ... Is it because I am putting the SID in the URL? I haven't tested with cookies yet as I want to get my site working without cookies first. Adding a logout feature will help people who are worried about security, because it can kill the cookies on the browser. I agree! The problem I have now is that a user can bookmark a page with the SID in the URL and then come back later and the session is still active ... the session should close when the browser is closed. I have set session.auto_start = 1 so I would think that after closing the browser and going to the bookmarked paged a new session would be started, killing the SID passed in from the URL no? Thanks! Jc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and trans-sid problem/question
PHP cannot possibly know when a user closes a window... PHP regularly cleans out the garbage of old abandoned sessions, but you cannot expect this instantly... the only way to kill a session is to kill it on the server with session_destroy(), which will require the user to access a logout script, or some javascript trickery... If you access that URL tomorrow, I doubt the session will STILL be valid... You should do some reading up in the manual php.ini, making sure what session destroy means, what session.auto_start means, etc. Justin on 22/11/02 6:02 PM, Jean-Christian Imbeault ([EMAIL PROTECTED]) wrote: Justin French wrote: I know that for IE Mac users (not sure about NN7) it's not until you QUIT the application that the session is terminated... I *think* you'll find something similar in Windows... perhaps when ALL open browser windows are closed and/or the browser app is QUIT, the session will end? I exited all apps and restarted the browser. Didn't help. I also copy-pasted the URL (http://192.168.254.14/my_account.html?step=order_listPHPSESSID=b6f60469a3a67 b677cf9c13e34b17072) from my Netscape 7 browser into an IE browser and the sessions was still valid ... Is it because I am putting the SID in the URL? I haven't tested with cookies yet as I want to get my site working without cookies first. Adding a logout feature will help people who are worried about security, because it can kill the cookies on the browser. I agree! The problem I have now is that a user can bookmark a page with the SID in the URL and then come back later and the session is still active ... the session should close when the browser is closed. I have set session.auto_start = 1 so I would think that after closing the browser and going to the bookmarked paged a new session would be started, killing the SID passed in from the URL no? Thanks! Jc Justin French http://Indent.com.au Web Developent Graphic Design -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
