Re: [PHP] sessions working? not working?

[Tedd Sperling]

On Aug 12, 2013, at 4:27 AM, Clifford Shuker  
wrote:
> Hi have the following (below) session code at the top of each page..  The
> 'print_r' (development feature only) confirms that on one particular page I
> do log out as the session var = (). but, on testing that page via the URL I
> still get to see the page and all its contents - session var() -..  the page
> has the following  'session_start, DOCTYPE Info then containing
> meta info & titlecontaining style/tables/content/
> // end of page.  I have copied the same page without the html content (i.e.
> a blank page) and I get to fully log out.. when this page is tested in the
> URL my warning comes up 'you need to login to see this page' which is what I
> want but, I've tried numerous avenues to reconcile my problem to no avail..
> I'm a novice so any help would be appreciated..   
> 
> 
> 
>  
> session_start();
> 
> error_reporting (E_ALL ^ E_NOTICE);
> 
> $userid = $_SESSION['userid'];
> 
> $username = $_SESSION['username'];
> 
> print_r($_SESSION);
> 
> ?>
> 

Ok, but when are you populating the SESSION's? Such as:

$_SESSION['userid'] = $userid;

Also, have a look at this:

http://sperling.com/php/authorization/log-on.php

It might help.

tedd

___
tedd sperling
tedd.sperl...@gmail.com




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and expirations and isolations

[tamouse mailing lists]

On Tue, Jan 17, 2012 at 5:17 PM, Haluk Karamete  wrote:
> This brings the question to the following;
> WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER?

Just addressing this quesiton -- you are correct that the browser does
not tell the application when it closes. What *does* happen is that
the cookie associated with that browser session is destroyed or
nullified, thus when the use reopens their browser and opens the
application again, there won't be a session cookie sent to the
application on start.

As explained above, this has nothing to do with how long the session
data may be stored on the server, it just won't be accessed if the
browser has been closed in the meantime.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] sessions and expirations and isolations

[Ford, Mike]

> -Original Message-
> From: Stuart Dallas [mailto:stu...@3ft9.com]
> Sent: 18 January 2012 12:02
> 
> On 17 Jan 2012, at 23:17, Haluk Karamete wrote:
> 
> > I'm afraid session.cookie_lifetime = 0 keeps all session data (
> that
> > is past and present ) in server memory until a server restart/stop
> > takes place. Correct me if I'm wrong.
> 
> You are wrong. What you need to understand is that the cleanup of
> the data is controlled by a completely separate system to that which
> enables requests to get access to it. The session.gc_maxlifetime
> setting controls how long it must be since the session data was
> saved before it is considered for cleanup. The description above is
> correct in that the default behaviour is for the session cookie to
> die with the browser session, but that has absolutely no effect on
> how long the data will be retained on the server.

And you are also possibly wrong that session information is kept in
system memory, as the default is for it to be serialized and saved in
a regular file on disk. There are other options (database, shared memory,
...), but disk files are the default.

Cheers!

Mike

-- 
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,  
Portland PD507, City Campus, Leeds Metropolitan University,
Portland Way, LEEDS,  LS1 3HE,  United Kingdom 
E: m.f...@leedsmet.ac.uk T: +44 113 812 4730






To view the terms under which this email is distributed, please go to 
http://disclaimer.leedsmet.ac.uk/email.htm

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and expirations and isolations

[Stuart Dallas]

On 17 Jan 2012, at 23:17, Haluk Karamete wrote:

> Back to this session expiration...
> 
> that old quote said...
> 
> The default behaviour for sessions is to keep a session open
> indefinitely and only to expire a session when the browser is closed.
> This behaviour can be changed in the php.ini file by altering the
> line:
> 
> session.cookie_lifetime = 0
> If you wanted the session to finish in 5 minutes you would set this to:
> session.cookie_lifetime = 300.
> 
> 
> Reflecting on this a little more, I got interested in the part that
> says "The default behaviour for sessions is to keep a session open
> indefinitely and only to expire a session when the browser is closed."
> 
> How would do the server know that a browser is closed? No browser
> sends such a data to a server.
> 
> If you re-open your browser, sure you will get asked to relogin (
> cause that session id cookie is gone ) but that does not mean that old
> session data has been erased form the server. How could it?  The only
> way for that to happen is to run session_destroy programmatically but
> for that your users has to click on a link. Certainly, closing a
> browser won't cause that!
> 
> This brings the question to the following;
> WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER?
> 
> I'm afraid session.cookie_lifetime = 0 keeps all session data ( that
> is past and present ) in server memory until a server restart/stop
> takes place. Correct me if I'm wrong.

You are wrong. What you need to understand is that the cleanup of the data is 
controlled by a completely separate system to that which enables requests to 
get access to it. The session.gc_maxlifetime setting controls how long it must 
be since the session data was saved before it is considered for cleanup. The 
description above is correct in that the default behaviour is for the session 
cookie to die with the browser session, but that has absolutely no effect on 
how long the data will be retained on the server.

If you want a full description of how the session cleanup logic works I'm happy 
to provide it, but you should be able to work it out by looking at the 
descriptions of the gc_probability, gc_divisor and gc_maxlifetime settings on 
this page: 
http://www.php.net/manual/en/session.configuration.php#ini.session.gc-probability

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] sessions and expirations and isolations

[Haluk Karamete]

Back to this session expiration...

that old quote said...

The default behaviour for sessions is to keep a session open
indefinitely and only to expire a session when the browser is closed.
This behaviour can be changed in the php.ini file by altering the
line:

session.cookie_lifetime = 0
If you wanted the session to finish in 5 minutes you would set this to:
session.cookie_lifetime = 300.


Reflecting on this a little more, I got interested in the part that
says "The default behaviour for sessions is to keep a session open
indefinitely and only to expire a session when the browser is closed."

How would do the server know that a browser is closed? No browser
sends such a data to a server.

If you re-open your browser, sure you will get asked to relogin (
cause that session id cookie is gone ) but that does not mean that old
session data has been erased form the server. How could it?  The only
way for that to happen is to run session_destroy programmatically but
for that your users has to click on a link. Certainly, closing a
browser won't cause that!

This brings the question to the following;
WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER?

I'm afraid session.cookie_lifetime = 0 keeps all session data ( that
is past and present ) in server memory until a server restart/stop
takes place. Correct me if I'm wrong.




On Mon, Jan 16, 2012 at 4:19 PM, Stuart Dallas  wrote:
> On 16 Jan 2012, at 22:51, Haluk Karamete wrote:
>
>> Hi, in ASP, sessions expire when the client does not request an asp
>> page for more than 20 min. (The 20 min thing is a server level setting
>> - which can be changed by IIS settings )  And sessions work out of the
>> box.
>>
>> I use sessions a lot. So, most likely, I would keep that style in my
>> PHP apps too.
>>
>> I read the following about PHP sessions...  I wanted to know how
>> accurate this info is.
>>
>> 
>> The default behaviour for sessions is to keep a session open
>> indefinitely and only to expire a session when the browser is closed.
>> This behaviour can be changed in the php.ini file by altering the
>> line:
>>
>> session.cookie_lifetime = 0
>> If you wanted the session to finish in 5 minutes you would set this to:
>>
>> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
>> session.cookie_lifetime = 300.
>> Remember to restart your web server after making this change.
>> 
>
> That's totally accurate, except that it doesn't touch upon how sessions are 
> cleaned up...
>
>> Now, if this info is correct and it is this simple, why do we have
>> some elaborate posts like this one?
>>
>> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes
>
> ...which explains that post. The session.cookie_lifetime is simply the expiry 
> time that will be set on the cookie that specifies the visitor's session ID. 
> That ID is used as the unique identifier on the server in the session storage 
> system (defaults to files of serialized data). If you want to have more 
> precise control over the session lifetime (though I can't see any reason why 
> you would need to) then you can write your own session handler and implement 
> the timeout logic yourself. You could also handle it by storing a timestamp 
> in the session and using that to decide whether the session data should be 
> considered valid (as described in the accepted answer on that post).
>
>> What do you do when you write a PHP app that relies on sessions? how
>> do you manage the server memory allocation issues?
>> Say you wanted to keep session vars alive for 20 min ( from the last
>> request from the client ) and you wanted your server to completely
>> empty the session if there no request, no new php page is requested
>> from that client within that next 20 min. And if a client requests a
>> page say on the 19th min, session gets extended another 20 from that
>> time on, just like the ASP works.
>
> The only reason there would be memory allocation issues is if you're storing 
> huge amounts of data in the session. If you are then I'd suggest that you 
> either re-architect your application so you don't need to, or implement a 
> custom storage mechanism for that data that doesn't use the session system.
>
>> My second question on session is abut keeping sessions apart from one
>> another - if such a concept exists...
>>
>> Let's say you have a session var FirstName in app1 and another session
>> variable exactly named as FirstName in app2.
>> how do you keep them seperate?
>>
>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>> dir path to the app, and from that point on, any page being served
>> under that virtual path is treated as an isolated ASP app and thus the
>> sessions are kept isolated and not get mixed up by asp pages that do
>> not live under that virtual app path.
>
>
> I don't know much about the way ASP implements sessions but I highly doubt 
> there is anything significantly different in there to th

Re: [PHP] sessions and expirations and isolations

[Haluk Karamete]

great exp. now I'm heading towards the
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path.

you definitely deserved a good  chocolate cookie!

On Mon, Jan 16, 2012 at 6:38 PM, Stuart Dallas  wrote:
> On 17 Jan 2012, at 02:21, Haluk Karamete wrote:
>
>> Well Stuart,
>>
>> When I said this
>>
>>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>>> dir path to the app, and from that point on, any page being served
>>> under that virtual path is treated as an isolated ASP app and thus the
>>> sessions are kept isolated and not get mixed up by asp pages that do
>>> not live under that virtual app path.
>>
>> I did not mean that aspect of the business which you replied to.  I
>> did not mean that 2 user's session can get being mixed up. Of course,
>> neither PHP nor ASP would allow that and that's all thru the current
>> session cookie ID - which is nearly impossible to guess for somebody
>> else's session cookie ID for that session time.
>>
>> Instead, I was meaning something totally different. Sorry for not
>> being very clear about it. Here is another shot at it.
>>
>> Here, you are developing an app and the app is being developed under say
>> domain.com/app1/. Let's call this app APP_1
>> And this app got say 10 php files and these files use lots of some
>> session vars to pass some data from one another. That's the case for
>> APP_1.
>>
>> now you need a second app... which is totally different that APP_1.
>> And that is to be developed under say the same server as say
>> domain.com/APP_2/ and this one too has its 5 php files too.
>>
>> But there is nothing common between two apps.
>>
>> Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
>> separate apps ( virtual apps they call it ) and once I do that  ( and
>> that's thru the IS settings ), the sessions vars I store in APP_1 does
>> not get overwritten by the APP_2, even though they may or may not
>> share the ame names... With that,  I can set up a session var "Age" as
>> 43 right there in APP_1 and I can have another session variable in the
>> other app, still named as "Age" where I store age value as a string,
>> something like say  "middle-age". If I weren't create these virtual
>> apps at IIS, ASP would have overwritten the value 43 with the value
>> middle-age and vice versa back and forth.
>>
>> I'm trying to understand if the same flexibility is available or not with 
>> PHP.
>> I should be able to go the APP_1 and do a _SESSION dump and I should
>> see 10 session variables in there and then I should be able to go
>> APP_2 and there I should se only 8. That's the case with classic ASP.
>
> Of course. I did touch on this in my reply but I obviously wasn't verbose 
> enough. Sessions are tied to an ID, and that ID is (usually) stored in a 
> cookie. Therefore the cookie is what links a session to a user, and it's the 
> limits on that cookie that determine the level of isolation.
>
> In the case you describe above, the default behaviour would be for both apps 
> to share the session because the cookie would be set on domain.com with the 
> default path of /. You can change the path with the session.cookie_path 
> setting. See here for more details: 
> http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path
>
> Basically, each app would need to use the ini_set function to set 
> session.cookie_path to /APP_1 or /APP_2 accordingly, before calling 
> session_start. That will effectively isolate the sessions for the two apps in 
> the same way that virtual directories do in ASP.
>
> Hope that makes it clearer.
>
> -Stuart
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and expirations and isolations

[Stuart Dallas]

On 17 Jan 2012, at 02:21, Haluk Karamete wrote:

> Well Stuart,
> 
> When I said this
> 
>> In ASP, I create a virtual app at the IIS server - assigning a virtual
>> dir path to the app, and from that point on, any page being served
>> under that virtual path is treated as an isolated ASP app and thus the
>> sessions are kept isolated and not get mixed up by asp pages that do
>> not live under that virtual app path.
> 
> I did not mean that aspect of the business which you replied to.  I
> did not mean that 2 user's session can get being mixed up. Of course,
> neither PHP nor ASP would allow that and that's all thru the current
> session cookie ID - which is nearly impossible to guess for somebody
> else's session cookie ID for that session time.
> 
> Instead, I was meaning something totally different. Sorry for not
> being very clear about it. Here is another shot at it.
> 
> Here, you are developing an app and the app is being developed under say
> domain.com/app1/. Let's call this app APP_1
> And this app got say 10 php files and these files use lots of some
> session vars to pass some data from one another. That's the case for
> APP_1.
> 
> now you need a second app... which is totally different that APP_1.
> And that is to be developed under say the same server as say
> domain.com/APP_2/ and this one too has its 5 php files too.
> 
> But there is nothing common between two apps.
> 
> Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
> separate apps ( virtual apps they call it ) and once I do that  ( and
> that's thru the IS settings ), the sessions vars I store in APP_1 does
> not get overwritten by the APP_2, even though they may or may not
> share the ame names... With that,  I can set up a session var "Age" as
> 43 right there in APP_1 and I can have another session variable in the
> other app, still named as "Age" where I store age value as a string,
> something like say  "middle-age". If I weren't create these virtual
> apps at IIS, ASP would have overwritten the value 43 with the value
> middle-age and vice versa back and forth.
> 
> I'm trying to understand if the same flexibility is available or not with PHP.
> I should be able to go the APP_1 and do a _SESSION dump and I should
> see 10 session variables in there and then I should be able to go
> APP_2 and there I should se only 8. That's the case with classic ASP.

Of course. I did touch on this in my reply but I obviously wasn't verbose 
enough. Sessions are tied to an ID, and that ID is (usually) stored in a 
cookie. Therefore the cookie is what links a session to a user, and it's the 
limits on that cookie that determine the level of isolation.

In the case you describe above, the default behaviour would be for both apps to 
share the session because the cookie would be set on domain.com with the 
default path of /. You can change the path with the session.cookie_path 
setting. See here for more details: 
http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path

Basically, each app would need to use the ini_set function to set 
session.cookie_path to /APP_1 or /APP_2 accordingly, before calling 
session_start. That will effectively isolate the sessions for the two apps in 
the same way that virtual directories do in ASP.

Hope that makes it clearer.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and expirations and isolations

[Haluk Karamete]

Well Stuart,

When I said this

> In ASP, I create a virtual app at the IIS server - assigning a virtual
> dir path to the app, and from that point on, any page being served
> under that virtual path is treated as an isolated ASP app and thus the
> sessions are kept isolated and not get mixed up by asp pages that do
> not live under that virtual app path.

I did not mean that aspect of the business which you replied to.  I
did not mean that 2 user's session can get being mixed up. Of course,
neither PHP nor ASP would allow that and that's all thru the current
session cookie ID - which is nearly impossible to guess for somebody
else's session cookie ID for that session time.

Instead, I was meaning something totally different. Sorry for not
being very clear about it. Here is another shot at it.

Here, you are developing an app and the app is being developed under say
domain.com/app1/. Let's call this app APP_1
And this app got say 10 php files and these files use lots of some
session vars to pass some data from one another. That's the case for
APP_1.

now you need a second app... which is totally different that APP_1.
And that is to be developed under say the same server as say
domain.com/APP_2/ and this one too has its 5 php files too.

But there is nothing common between two apps.

Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two
separate apps ( virtual apps they call it ) and once I do that  ( and
that's thru the IS settings ), the sessions vars I store in APP_1 does
not get overwritten by the APP_2, even though they may or may not
share the ame names... With that,  I can set up a session var "Age" as
43 right there in APP_1 and I can have another session variable in the
other app, still named as "Age" where I store age value as a string,
something like say  "middle-age". If I weren't create these virtual
apps at IIS, ASP would have overwritten the value 43 with the value
middle-age and vice versa back and forth.

I'm trying to understand if the same flexibility is available or not with PHP.
I should be able to go the APP_1 and do a _SESSION dump and I should
see 10 session variables in there and then I should be able to go
APP_2 and there I should se only 8. That's the case with classic ASP.




On Mon, Jan 16, 2012 at 4:19 PM, Stuart Dallas  wrote:
> On 16 Jan 2012, at 22:51, Haluk Karamete wrote:
>
>> Hi, in ASP, sessions expire when the client does not request an asp
>> page for more than 20 min. (The 20 min thing is a server level setting
>> - which can be changed by IIS settings )  And sessions work out of the
>> box.
>>
>> I use sessions a lot. So, most likely, I would keep that style in my
>> PHP apps too.
>>
>> I read the following about PHP sessions...  I wanted to know how
>> accurate this info is.
>>
>> 
>> The default behaviour for sessions is to keep a session open
>> indefinitely and only to expire a session when the browser is closed.
>> This behaviour can be changed in the php.ini file by altering the
>> line:
>>
>> session.cookie_lifetime = 0
>> If you wanted the session to finish in 5 minutes you would set this to:
>>
>> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
>> session.cookie_lifetime = 300.
>> Remember to restart your web server after making this change.
>> 
>
> That's totally accurate, except that it doesn't touch upon how sessions are 
> cleaned up...
>
>> Now, if this info is correct and it is this simple, why do we have
>> some elaborate posts like this one?
>>
>> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes
>
> ...which explains that post. The session.cookie_lifetime is simply the expiry 
> time that will be set on the cookie that specifies the visitor's session ID. 
> That ID is used as the unique identifier on the server in the session storage 
> system (defaults to files of serialized data). If you want to have more 
> precise control over the session lifetime (though I can't see any reason why 
> you would need to) then you can write your own session handler and implement 
> the timeout logic yourself. You could also handle it by storing a timestamp 
> in the session and using that to decide whether the session data should be 
> considered valid (as described in the accepted answer on that post).
>
>> What do you do when you write a PHP app that relies on sessions? how
>> do you manage the server memory allocation issues?
>> Say you wanted to keep session vars alive for 20 min ( from the last
>> request from the client ) and you wanted your server to completely
>> empty the session if there no request, no new php page is requested
>> from that client within that next 20 min. And if a client requests a
>> page say on the 19th min, session gets extended another 20 from that
>> time on, just like the ASP works.
>
> The only reason there would be memory allocation issues is if you're storing 
> huge amounts of data in the session. If you are then I'd suggest that you 
> either re-architect

Re: [PHP] sessions and expirations and isolations

[Stuart Dallas]

On 16 Jan 2012, at 22:51, Haluk Karamete wrote:

> Hi, in ASP, sessions expire when the client does not request an asp
> page for more than 20 min. (The 20 min thing is a server level setting
> - which can be changed by IIS settings )  And sessions work out of the
> box.
> 
> I use sessions a lot. So, most likely, I would keep that style in my
> PHP apps too.
> 
> I read the following about PHP sessions...  I wanted to know how
> accurate this info is.
> 
> 
> The default behaviour for sessions is to keep a session open
> indefinitely and only to expire a session when the browser is closed.
> This behaviour can be changed in the php.ini file by altering the
> line:
> 
> session.cookie_lifetime = 0
> If you wanted the session to finish in 5 minutes you would set this to:
> 
> Listing 23 Keeping a session alive for five minutes (listing-23.txt)
> session.cookie_lifetime = 300.
> Remember to restart your web server after making this change.
> 

That's totally accurate, except that it doesn't touch upon how sessions are 
cleaned up...

> Now, if this info is correct and it is this simple, why do we have
> some elaborate posts like this one?
> 
> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes

...which explains that post. The session.cookie_lifetime is simply the expiry 
time that will be set on the cookie that specifies the visitor's session ID. 
That ID is used as the unique identifier on the server in the session storage 
system (defaults to files of serialized data). If you want to have more precise 
control over the session lifetime (though I can't see any reason why you would 
need to) then you can write your own session handler and implement the timeout 
logic yourself. You could also handle it by storing a timestamp in the session 
and using that to decide whether the session data should be considered valid 
(as described in the accepted answer on that post).

> What do you do when you write a PHP app that relies on sessions? how
> do you manage the server memory allocation issues?
> Say you wanted to keep session vars alive for 20 min ( from the last
> request from the client ) and you wanted your server to completely
> empty the session if there no request, no new php page is requested
> from that client within that next 20 min. And if a client requests a
> page say on the 19th min, session gets extended another 20 from that
> time on, just like the ASP works.

The only reason there would be memory allocation issues is if you're storing 
huge amounts of data in the session. If you are then I'd suggest that you 
either re-architect your application so you don't need to, or implement a 
custom storage mechanism for that data that doesn't use the session system.

> My second question on session is abut keeping sessions apart from one
> another - if such a concept exists...
> 
> Let's say you have a session var FirstName in app1 and another session
> variable exactly named as FirstName in app2.
> how do you keep them seperate?
> 
> In ASP, I create a virtual app at the IIS server - assigning a virtual
> dir path to the app, and from that point on, any page being served
> under that virtual path is treated as an isolated ASP app and thus the
> sessions are kept isolated and not get mixed up by asp pages that do
> not live under that virtual app path.


I don't know much about the way ASP implements sessions but I highly doubt 
there is anything significantly different in there to the way PHP does it. For 
all intents and purposes the isolation of a given user's session is guaranteed 
by the use of cookies. As I mentioned earlier, the session ID is stored in a 
cookie. Cookies are not shared between domain names, so there is no way that 
two sites, or "applications", could use the same session [1].

-Stuart

[1] This is not entirely true, but since it requires some nasty trickery to 
make it happen it's not something you need to worry about unless it sharing 
sessions is required which is incredibly rare and almost certainly another sign 
of poor architecture!

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions - More Info

[Boers Steven]

Dear List -

Thank you for your help in the past.  This an update on my session 
problems.


Here is a simple test program.  It never increments the session counter; 
ie, does not detect that $_SESSION has been set.




"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>







I have no idea what is wrong.

I need to make my session variables work so that I can finish a project.

Help and advice, please.

Ethan Rosenberg

MySQL 5.1  PHP 5.3.3-6  Linux [Debian (sid)]

I tried your code on my testing computer (PHP 5.2.14) and everything works 
fine. $_SESSION['views'] is counting up correctly. Maybe a problem with your 
configuration?


Beste regards.
Steven


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions - More Info - SOLVED

[Ethan Rosenberg]

At 07:28 PM 3/30/2011, Ashley Sheridan wrote:

On Wed, 2011-03-30 at 19:20 -0400, Ethan Rosenberg wrote:

> Dear List -
>
> Thank you for your help in the past.  This an update on my 
session problems.

>
> Here is a simple test program.  It never increments the session
> counter; ie, does not detect that $_SESSION has been set.
>
> 
>
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";>
> 
> 
>
> 
>
> if(isset($_SESSION['views']))
> $_SESSION['views']=$_SESSION['views']+1;
> else
> $_SESSION['views']=1;
> echo "Views=". $_SESSION['views'];
> ?>
>  
> 
>
> I have no idea what is wrong.
>
> I need to make my session variables work so that I can finish a project.
>
> Help and advice, please.
>
> Ethan Rosenberg
>
> MySQL 5.1  PHP 5.3.3-6  Linux [Debian (sid)]
>
>
>


That code works perfectly for me, only thing I would change is the

$_SESSION['views']=$_SESSION['views']+1;

line to

$_SESSION['views']++;

for readability. If you're using Firefox, grab the Firebug plugin, which
should show you the headers that are being sent to and from the server
to the browser. From that, you might get an idea why the sessions don't
seem to be working. Just to make sure, turn on display_errors in your
php.ini file and restart Apache. Some whitespace (space or new line, for
example) before that first http://www.ashleysheridan.co.uk


++
Ash -

Thanks.

What did it was to 1] explicitly declare the character set and 2] 
close and restart Apache.


Ethan 




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions - More Info

[Ashley Sheridan]

On Wed, 2011-03-30 at 19:20 -0400, Ethan Rosenberg wrote:

> Dear List -
> 
> Thank you for your help in the past.  This an update on my session problems.
> 
> Here is a simple test program.  It never increments the session 
> counter; ie, does not detect that $_SESSION has been set.
> 
> 
> 
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";>
> 
> 
> 
>  
> 
> if(isset($_SESSION['views']))
> $_SESSION['views']=$_SESSION['views']+1;
> else
> $_SESSION['views']=1;
> echo "Views=". $_SESSION['views'];
> ?>
>  
> 
> 
> I have no idea what is wrong.
> 
> I need to make my session variables work so that I can finish a project.
> 
> Help and advice, please.
> 
> Ethan Rosenberg
> 
> MySQL 5.1  PHP 5.3.3-6  Linux [Debian (sid)] 
> 
> 
> 


That code works perfectly for me, only thing I would change is the

$_SESSION['views']=$_SESSION['views']+1;

line to

$_SESSION['views']++;

for readability. If you're using Firefox, grab the Firebug plugin, which
should show you the headers that are being sent to and from the server
to the browser. From that, you might get an idea why the sessions don't
seem to be working. Just to make sure, turn on display_errors in your
php.ini file and restart Apache. Some whitespace (space or new line, for
example) before that first http://www.ashleysheridan.co.uk

Re: [PHP] Sessions only work in SSL

[Daniel Houle]

On 10/19/2010 09:41 AM, Andrew Ballard wrote:

On Mon, Oct 18, 2010 at 8:46 PM, Daniel Houle  wrote:

I have a strange issue here.  I am running a CentOS machine, with

apache 2.2.3
php 5.1.6
kernel 2.6.18-194.8.1.el5xen

My sessions will work using https, but not using simple http.  I've compared
my configs with another identical machine which works with both, and I can't
figure out why.  Anyone got an idea?

Here's the simple script I run to test.

' . $_SESSION['name'];
  session_destroy();
} else {
  echo 'No session found';
  $_SESSION['name'] = 'My session';
}

phpinfo();
?>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Are you sure session.cookie_secure is not turned on somewhere?

Andrew

No, it was not set anywhere.  But I did add it in with

session.cookie_secure 0

and it solved my issue.  Thank you very much Andrew!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions only work in SSL

[Andrew Ballard]

On Mon, Oct 18, 2010 at 8:46 PM, Daniel Houle  wrote:
> I have a strange issue here.  I am running a CentOS machine, with
>
> apache 2.2.3
> php 5.1.6
> kernel 2.6.18-194.8.1.el5xen
>
> My sessions will work using https, but not using simple http.  I've compared
> my configs with another identical machine which works with both, and I can't
> figure out why.  Anyone got an idea?
>
> Here's the simple script I run to test.
>
> 
> session_start();
>
> echo 'session started';
>
> if (isset($_SESSION['name'])) {
>  echo '' . $_SESSION['name'];
>  session_destroy();
> } else {
>  echo 'No session found';
>  $_SESSION['name'] = 'My session';
> }
>
> phpinfo();
> ?>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Are you sure session.cookie_secure is not turned on somewhere?

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions and Security Concerns

[Nathan Rixham]

Ashley Sheridan wrote:
> On Mon, 2010-03-29 at 12:24 +0100, Ben Stones wrote:
> 
>> Hi,
>>
>> I'm just wondering whether there are any apparent security concerns I should
>> be aware of when using sessions in my PHP scripts. I understand that
>> sessions are tracked with an individual user via a session ID which is
>> stored in a temporary location on the server, as well as a PHPSESSID cookie
>> assigned to the end user's client, but the server my website is hosted on
>> (and which I'll be developing my PHP script on) doesn't allow you to create
>> a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
>> the server can generate a session ID for the end user when I call the
>> session_start function? So do I still need to call session_regenerate_id for
>> security purposes when an end user has entered the correct login credentials
>> - would this be necessary since you cant set a session ID via the URL?
>>
>> Thanks,
>> Ben.
> 
> 
> Just setting a URL variable won't actually create a session, you have to
> use the PHP session functions to create one.
> 
> Using session_regenerate_id() won't do that much for security. If you
> are really worried, then consider a security certificate. Even a
> self-issued one is better than nothing, and you can generate these for
> free.

worth noting that you can also issue client side ssl certificates to
your users; 100% secure, self-signed thus free, either by creating a
pki12 w/ php or by using the html KEYGEN element - the ssl cert installs
directly in the users browser. You can use the subjectAltName attribute
of the certificate to save a users unique id.

And thus, 0 click login, perfectly secure auth all done through https -
further meaning you can completely negate sessions/cookies and all the
related insecurities.

further still, you can boot this up to foaf+ssl giving users one unique
web id for themselves, and in full control of there own profile / login
etc; (like openid done right and one steriods)

Will be the defacto industry standard in a couple of years, so may as
well adopt early.

Regards!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions and Security Concerns

[Ashley Sheridan]

On Mon, 2010-03-29 at 12:24 +0100, Ben Stones wrote:

> Hi,
> 
> I'm just wondering whether there are any apparent security concerns I should
> be aware of when using sessions in my PHP scripts. I understand that
> sessions are tracked with an individual user via a session ID which is
> stored in a temporary location on the server, as well as a PHPSESSID cookie
> assigned to the end user's client, but the server my website is hosted on
> (and which I'll be developing my PHP script on) doesn't allow you to create
> a session ID via the URL (i.e. index.php?PHPSESSID=1234) so I *presume* only
> the server can generate a session ID for the end user when I call the
> session_start function? So do I still need to call session_regenerate_id for
> security purposes when an end user has entered the correct login credentials
> - would this be necessary since you cant set a session ID via the URL?
> 
> Thanks,
> Ben.


Just setting a URL variable won't actually create a session, you have to
use the PHP session functions to create one.

Using session_regenerate_id() won't do that much for security. If you
are really worried, then consider a security certificate. Even a
self-issued one is better than nothing, and you can generate these for
free.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: Re[2]: [PHP] Re: PHP Sessions

[Ashley Sheridan]

On Sat, 2010-03-13 at 12:49 +0200, Andre Polykanine wrote:

> Hello Ashley,
> 
> And if the site is full of that code?)) I think it's worth to learn
> what's really the reason of the fact that it doesn't work. Besides
> that, it's more readable for me.
> And the right thing that was said here is the following: check the
> php.ini settings and change them if possible.
> 


If the site is full of that code I'd make a start on replacing it. A
simple find/replace will work in cases like this.

I try to write my code so that I don't have to make unnecessary changes
to my php.ini. For example, what if I don't have access to my php.ini
and can't set a directive in my .htaccess file? What if I'm sharing my
code with someone? What if I need to work with outputting XML headers?
All of these factors I think outweigh any gains I would get from short
tags.

As for readability, I tend to use a text editor with syntax highlighting
which makes my code readable.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re[2]: [PHP] Re: PHP Sessions

[Andre Polykanine]

Hello Ashley,

And if the site is full of that code?)) I think it's worth to learn
what's really the reason of the fact that it doesn't work. Besides
that, it's more readable for me.
And the right thing that was said here is the following: check the
php.ini settings and change them if possible.

-- 
With best regards from Ukraine,
Andre
Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
jabber.org
Yahoo! messenger: andre.polykanine; ICQ: 191749952
Twitter: m_elensule

- Original message -
From: Ashley Sheridan 
To: Andre Polykanine 
Date: Saturday, March 13, 2010, 12:33:46 PM
Subject: [PHP] Re: PHP Sessions

On Sat, 2010-03-13 at 12:22 +0200, Andre Polykanine wrote:

> Hello Martine,
> 
> As you have been already told, the  is not always supported.
> However I'd suggest you to do the following (since I love this form of
> tag):
>  «»
> 
>  Note: I put within the tag only the variable.
> 
> -- 
> With best regards from Ukraine,
> Andre
> Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
> jabber.org
> Yahoo! messenger: andre.polykanine; ICQ: 191749952
> Twitter: m_elensule
> 
> - Original message -
> From: Martine Osias 
> To: php-general@lists.php.net 
> Date: Saturday, March 13, 2010, 4:33:34 AM
> Subject: [PHP] Re: PHP Sessions
> 
> The sessions variables are OK. They don't print when I put them on the HTML 
> page with this code.
> 
> 
>  
>  
> 
> 
>   align="right">
>  
> 
> Thank you.
> 
> 
> Martine
> 
> ""Martine Osias""  wrote in message 
> news:95.0c.13686.c7cda...@pb1.pair.com...
> > Hi:
> >
> > I need to store variables to send then between pages. I don't need the 
> > variables in a database so I try to send them with sessions. The variables 
> > don't seem to be there when I try to get them. What could be the problem. 
> > Here are the pages where I store and retrieve the variables.
> >
> > Page 1 (variables stored):
> >
> >  >
> > session_start();
> >
> > $_SESSION['scripture_text']  = $row_scripture['ScriptureText'];
> > $_SESSION['scripture_ref']  = $row_scripture['ScriptureRef'];
> >
> > ?>
> >
> > Page 2 (variables retrieved):
> >
> >  > session_start();
> > include("includes/config.php");
> > ?>
> >  > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> > http://www.w3.org/1999/xhtml";>
> > 
> > 
> > 
> >
> > 
> >
> > 
> > 
> > 
> >
> > 
> >  > align="right">
> > 
> >
> > 
> >
> > 
> > 
> >
> > 
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


That's still using short tags. The time you save on typing is nothing
compared to the time you spend trying to figure out why your script
doesn't work since you moved servers, or copied it to your live server,
or why you are having trouble using XML...

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: PHP Sessions

[Ashley Sheridan]

On Sat, 2010-03-13 at 12:22 +0200, Andre Polykanine wrote:

> Hello Martine,
> 
> As you have been already told, the  is not always supported.
> However I'd suggest you to do the following (since I love this form of
> tag):
>  «»
> 
>  Note: I put within the tag only the variable.
> 
> -- 
> With best regards from Ukraine,
> Andre
> Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
> jabber.org
> Yahoo! messenger: andre.polykanine; ICQ: 191749952
> Twitter: m_elensule
> 
> - Original message -
> From: Martine Osias 
> To: php-general@lists.php.net 
> Date: Saturday, March 13, 2010, 4:33:34 AM
> Subject: [PHP] Re: PHP Sessions
> 
> The sessions variables are OK. They don't print when I put them on the HTML 
> page with this code.
> 
> 
>  
>  
> 
> 
>   align="right">
>  
> 
> Thank you.
> 
> 
> Martine
> 
> ""Martine Osias""  wrote in message 
> news:95.0c.13686.c7cda...@pb1.pair.com...
> > Hi:
> >
> > I need to store variables to send then between pages. I don't need the 
> > variables in a database so I try to send them with sessions. The variables 
> > don't seem to be there when I try to get them. What could be the problem. 
> > Here are the pages where I store and retrieve the variables.
> >
> > Page 1 (variables stored):
> >
> >  >
> > session_start();
> >
> > $_SESSION['scripture_text']  = $row_scripture['ScriptureText'];
> > $_SESSION['scripture_ref']  = $row_scripture['ScriptureRef'];
> >
> > ?>
> >
> > Page 2 (variables retrieved):
> >
> >  > session_start();
> > include("includes/config.php");
> > ?>
> >  > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> > http://www.w3.org/1999/xhtml";>
> > 
> > 
> > 
> >
> > 
> >
> > 
> > 
> > 
> >
> > 
> >  > align="right">
> > 
> >
> > 
> >
> > 
> > 
> >
> > 
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


That's still using short tags. The time you save on typing is nothing
compared to the time you spend trying to figure out why your script
doesn't work since you moved servers, or copied it to your live server,
or why you are having trouble using XML...

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Re: PHP Sessions

[Andre Polykanine]

Hello Martine,

As you have been already told, the  is not always supported.
However I'd suggest you to do the following (since I love this form of
tag):
 «»

 Note: I put within the tag only the variable.

-- 
With best regards from Ukraine,
Andre
Skype: Francophile; Wlm&MSN: arthaelon @ yandex.ru; Jabber: arthaelon @ 
jabber.org
Yahoo! messenger: andre.polykanine; ICQ: 191749952
Twitter: m_elensule

- Original message -
From: Martine Osias 
To: php-general@lists.php.net 
Date: Saturday, March 13, 2010, 4:33:34 AM
Subject: [PHP] Re: PHP Sessions

The sessions variables are OK. They don't print when I put them on the HTML 
page with this code.


 
 


 
 

Thank you.


Martine

""Martine Osias""  wrote in message 
news:95.0c.13686.c7cda...@pb1.pair.com...
> Hi:
>
> I need to store variables to send then between pages. I don't need the 
> variables in a database so I try to send them with sessions. The variables 
> don't seem to be there when I try to get them. What could be the problem. 
> Here are the pages where I store and retrieve the variables.
>
> Page 1 (variables stored):
>
> 
> session_start();
>
> $_SESSION['scripture_text']  = $row_scripture['ScriptureText'];
> $_SESSION['scripture_ref']  = $row_scripture['ScriptureRef'];
>
> ?>
>
> Page 2 (variables retrieved):
>
>  session_start();
> include("includes/config.php");
> ?>
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> http://www.w3.org/1999/xhtml";>
> 
> 
> 
>
> 
>
> 
> 
> 
>
> 
>  align="right">
> 
>
> 
>
> 
> 
>
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: PHP Sessions

[Ashley Sheridan]

On Fri, 2010-03-12 at 21:33 -0500, Martine Osias wrote:

> The sessions variables are OK. They don't print when I put them on the HTML 
> page with this code.
> 
> 
>  
>  
> 
> 
>   align="right">
>  
> 
> Thank you.
> 
> 
> Martine
> 
> ""Martine Osias""  wrote in message 
> news:95.0c.13686.c7cda...@pb1.pair.com...
> > Hi:
> >
> > I need to store variables to send then between pages. I don't need the 
> > variables in a database so I try to send them with sessions. The variables 
> > don't seem to be there when I try to get them. What could be the problem. 
> > Here are the pages where I store and retrieve the variables.
> >
> > Page 1 (variables stored):
> >
> >  >
> > session_start();
> >
> > $_SESSION['scripture_text']  = $row_scripture['ScriptureText'];
> > $_SESSION['scripture_ref']  = $row_scripture['ScriptureRef'];
> >
> > ?>
> >
> > Page 2 (variables retrieved):
> >
> >  > session_start();
> > include("includes/config.php");
> > ?>
> >  > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> > http://www.w3.org/1999/xhtml";>
> > 
> > 
> > 
> >
> > 
> >
> > 
> > 
> > 
> >
> > 
> >  > align="right">
> > 
> >
> > 
> >
> > 
> > 
> >
> > 
> 
> 


Don't use 

Short tags end up causing more problems than they solve sometimes...

Thanks,
Ash
http://www.ashleysheridan.co.uk

[PHP] Re: PHP Sessions

[Martine Osias]

The sessions variables are OK. They don't print when I put them on the HTML 
page with this code.







align="right">



Thank you.


Martine

""Martine Osias""  wrote in message 
news:95.0c.13686.c7cda...@pb1.pair.com...

Hi:

I need to store variables to send then between pages. I don't need the 
variables in a database so I try to send them with sessions. The variables 
don't seem to be there when I try to get them. What could be the problem. 
Here are the pages where I store and retrieve the variables.


Page 1 (variables stored):



Page 2 (variables retrieved):


"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

http://www.w3.org/1999/xhtml";>











align="right">












--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions across subdomains

[Jochem Maas]

Op 1/30/10 2:25 AM, Ben Miller schreef:
> Hi, I've always thought that session data was subdomain specific and would
> not carry over between http://www.mydomain.com and
> https://secure.mydomain.com, but it seems to be working for me now.  Can I
> rely on this and post from http://www.mydomain.com to
> https://secure.mydomain.com and simply pass a hidden input containing
> PHPSESSID, or do I need to pass each key=>value pair that _SESSION contains
> at www.  and reset them as _SESSION vars at secure.
>  ? 
> 

1. cookies are shared automatically on SUB domains, so if you set your cookie 
domain
to example.com it will be available at both www.example.com and 
secure.example.com

2. cookies can have a HTTPS flag set which means they will not be shared with 
non-HTTPS
connections.

3. DONT put the contents of $_SESSION on the wire. (given the question you're 
asking I'd
hazard a guess you don't have the skills to sufficiently

4. google/read/search/learn about the security implications of sharing a cookie 
between
HTTPS and non-HTTPS domains.

5. session_regenerate_id() - I would use this if you intend to pass session ids 
around,
although it will probably give you a stack of problems in terms of usability 
(e.g. back button usage),
actually I'd use it any time you log someone in or out or have a user perform a 
particularly
sensitive action.

6. the $_SESSION will only be available on both sites if they are both on the 
same server
and running with the same session ini settings (i.e. session save path, session 
name) - different
servers could obviously be using a shared filesystem or an alternative session 
storage (e.g.
memcached or database server).

7. consider not sharing the session - instead pass just the data that you need 
(e.g. shopping
basket contents etc) and either including a hash of the data (which uses a 
secret string that
is not included in the form/url/etc but that both servers/sites know about 
AND/OR using 2-way
public key encryption on the data that you pass in between the servers/sites

personally for higher end commercial sites I prefer to just to put everything 
on HTTPS
solving all potential issues with sharing a cookie or data between nonHTTPS and 
HTTPS sites,
and everything directly related ... the cost being extra overhead per request - 
but hardware
is cheap and security is difficult to get exactly right.

the biggest names on the web have [had] security loophopes/problems related to 
these issues, and they
generally have tons of man power and some very clever/knowledgable people on 
their teams - which is to say:
your chance (and mine for that matter) of not making any mistakes on this front 
are slimmer than theirs.

> Thanks in advance,
> 
> Ben
> 
> 


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: PHP sessions, AJAX, authentication and security.

[Angus Mann]

same as everywhere else in your apps.. ajax is no different in any way
at all, not even slightly. as far as PHP and web server is concerned
it's just a plain old request same as any other; thus..

if( !$_SESSION['is_logged_in'] ) {
 exit();
}
// do stuff




Thanks for that. Sometimes the solution is right there in front of you.
The bit of code below does the job nicely for me :

session_start();
if(!isset($_SESSION['username'])){
echo("Go Away.");
exit();
}
// now work with sensitive data...


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: PHP sessions, AJAX, authentication and security.

[Nathan Rixham]

Angus Mann wrote:
> Hi all.
> 
> A question about PHP sessions and their interaction with AJAX.
> 
> I have a database containing sensitive information and users need to log in 
> to my PHP script and be authenticated before they are granted access.
> 
> For one of the forms I would like to retrieve information using AJAX, and 
> some of that information is sensitive also. The request from AJAX is handled 
> by another, simpler PHP script.
> 
> It occurs to me that the AJAX handler could be used to bypass the user 
> authentication and a crafted request sent directly to the AJAX handler to get 
> information without authentication.
> 
> Can anyone offer some advice about how to piggy-back the 
> session/authentication data that the user originally used to the AJAX so that 
> only an authenticated user will get a valid response from the AJAX handler? I 
> know I could embed authentication information into the web-page and send this 
> with the AJAX request but I'm interested to know if there are other methods 
> also.
> 
> I hope the explanation is clear.
> 
> Thanks in advance. 

same as everywhere else in your apps.. ajax is no different in any way
at all, not even slightly. as far as PHP and web server is concerned
it's just a plain old request same as any other; thus..

if( !$_SESSION['is_logged_in'] ) {
  exit();
}
// do stuff

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and email

[Andrew Ballard]

On Thu, Nov 12, 2009 at 1:21 PM, Ashley Sheridan
 wrote:
> On Thu, 2009-11-12 at 13:17 -0500, Dan Shirah wrote:
>
>> All,
>>
>> I am using sessions for my application to verify a user has logged in:
>>
>> // Verify the user is logged in.
>> if (!isset($_SESSION['basic_is_logged_in'])
>>     || $_SESSION['basic_is_logged_in'] !== true) {
>>     // If not logged in, redirect to the login page.
>>     header('Location: login.php');
>>     exit;
>> }
>>
>> If anyone tries to go to any page in the application via the address bar,
>> they are correctly redirected to the login page.
>>
>> However, if someone that is currently logged into the application using I.E.
>> goes to File -> Send -> Page by Email, the person they email the link to can
>> open it and use the application without logging in and the address bar uses
>> a local path like: C:\Documents and Settings\my_name\Local
>> Settings\Temporary Internet Files\OLK18\My Page (2).htm
>>
>> How can I prevent the emailed pages from being able to access the
>> application if it is a local path or the user hasn't logged in?
>
>
> You can't really. When someone is emailing the page, it's the equivalent
> of them saving the page to their local computer, and then sending that
> as an attachment. As this is all client-side, it has no contact with
> PHP. You could have some sort of Javascript to detect the domain the
> page has, and then redirect if it's not your domain, but this fails when
> someone turns Javascript off. Apart from that, I don't know of any other
> way you could stop someone from emailing a page, aside from making the
> site completely Ajax based and pulling in every scrap of content via
> Ajax.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>

And even then, it has become part of the DOM and will be saved with
the rest of the page. The presence of Javascript in the page *might*
remove it/hide it/obscure it/etc., but it will still be there in the
saved document.

Andrew

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions and email

[Ashley Sheridan]

On Thu, 2009-11-12 at 13:17 -0500, Dan Shirah wrote:

> All,
> 
> I am using sessions for my application to verify a user has logged in:
> 
> // Verify the user is logged in.
> if (!isset($_SESSION['basic_is_logged_in'])
> || $_SESSION['basic_is_logged_in'] !== true) {
> // If not logged in, redirect to the login page.
> header('Location: login.php');
> exit;
> }
> 
> If anyone tries to go to any page in the application via the address bar,
> they are correctly redirected to the login page.
> 
> However, if someone that is currently logged into the application using I.E.
> goes to File -> Send -> Page by Email, the person they email the link to can
> open it and use the application without logging in and the address bar uses
> a local path like: C:\Documents and Settings\my_name\Local
> Settings\Temporary Internet Files\OLK18\My Page (2).htm
> 
> How can I prevent the emailed pages from being able to access the
> application if it is a local path or the user hasn't logged in?


You can't really. When someone is emailing the page, it's the equivalent
of them saving the page to their local computer, and then sending that
as an attachment. As this is all client-side, it has no contact with
PHP. You could have some sort of Javascript to detect the domain the
page has, and then redirect if it's not your domain, but this fails when
someone turns Javascript off. Apart from that, I don't know of any other
way you could stop someone from emailing a page, aside from making the
site completely Ajax based and pulling in every scrap of content via
Ajax.

Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Sessions seems to kill db connection

[Kim Madsen]

Hi Kranthi

kranthi wrote on 2009-10-24 07:27:

Db error: Access denied for user 'www-data'@'localhost' (using password: NO)



WTF? I´m not using a user called www-data for MySQL connections, but apache 
runs as this user


in the case where $test is true there is an open mysql connection, but
when $test is false there is no open connection is  available. may be
you have opened a connection when $test is true or used a
mysql_close() when $test is false or when $_SESSION['login']['uid'] is
set.


I think you missed my words about resolving the matter, when you were 
cutting the quoted text :-)



regarding www-data, when mysql_query() fails to find a valid MySql
connection, it tries to open a new connection with mysql.default_user
and mysql.default_password (u can see these values trough phpinfo());
http://php.net/manual/en/function.mysql-connect.php


Thanks, that explained the www-data user

--
Kind regards
Kim Emax - masterminds.dk

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions seems to kill db connection

[kranthi]

>> Db error: Access denied for user 'www-data'@'localhost' (using password: NO)

>> WTF? I´m not using a user called www-data for MySQL connections, but apache 
>> runs as this user

in the case where $test is true there is an open mysql connection, but
when $test is false there is no open connection is  available. may be
you have opened a connection when $test is true or used a
mysql_close() when $test is false or when $_SESSION['login']['uid'] is
set.

regarding www-data, when mysql_query() fails to find a valid MySql
connection, it tries to open a new connection with mysql.default_user
and mysql.default_password (u can see these values trough phpinfo());
http://php.net/manual/en/function.mysql-connect.php

this used to be the behavior earlier, seems it was changed from PHP > 5.3.0

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions seems to kill db connection

[Kim Madsen]

Kim Madsen wrote on 2009-10-22 17:51:

Hi PHPeople

I have an odd problem at my new work and wonder if it's some sort of odd 
setup that is causing this problem when using sessions:


Like I said, my new work and odd setup, an include file had a 
mysql_close() in the bottom


Speaking of mysql_close(), I think I've read somewhere that in PHP6 a db 
connection will not be closed, when the script is done. Is this true? 
Cause then it would definetly be best practice to to _always_ have a 
mysql_close() in the end for the main file.


--
Kind regards
Kim Emax - masterminds.dk

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes - SOLVED

[Angelo Zanetti]

-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 24 August 2009 04:30 PM
To: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes



-Original Message-
From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
Sent: 20 August 2009 02:58 PM
To: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

On Thu, Aug 20, 2009 at 02:34:54PM +0200, Angelo Zanetti wrote:
> Hi Leon, 
> 
> No harm intended :) Just thought that people were missing my post now and
> only answering yours.
> 

Angelo, excuse me if I'm bringing up something very basic, but I'm new
to this.  Just trying to help.  

I imagine redirects couldn't be the cause of the problem, right?  

http://www.oscarm.org/news/detail/1877-avoiding_frustration_with_php_session
s

http://www.webmasterworld.com/forum88/8486.htm


Hi thanks for the links it appears that its all in order also I'm not losing
SESSIONS on the redirect but somewhere else.

I have checked the garbage collection, disk space and other settings in the
PHP.ini file. ALL FINE.

So now I am really stuck and confused as to what could sometimes cause the
loss of these variables and other times it just works fine. 

Is there possibly a way that I can call some function that will ensure that
the sessions are saved (I checked the manual - nothing much).

Any other ideas? Anything that you think might be causing issues? 

Thanks
Angelo

Hi all, 

I have solved the issue of lost session variables.

It appeared to be losing the SESSION variables when going from a POST from
HTTP to HTTPS, however it didn't always happen, so the logging allowed me to
narrow down where the losing was occurring.

The solution.

In my form that I post from the HTTP site, I put a hidden variable in there
and with the session variable. 

In HTTPS it sometimes doesn't carry over the hidden variable therefore we
need to start the session with the old SESSION ID from the HTTP site.

So what I did was the following on the https site: 

if (isset($_POST['sessionID']))
{

//http://stackoverflow.com/questions/441496/session-lost-when-switching-from
-http-to-https-in-php
// Retrieve the session ID as passed via the GET method.
$currentSessionID = $_POST['sessionID'];
//echo $currentSessionID;
// Set a cookie for the session ID.
$sessionid2 = session_id($currentSessionID);
}

Therefore setting the session ID with the session_id() function. This must
go before the session_start() function!!! Very NB!.

Hope this helps anyone who has a similar problem.

Regards
Angelo

http://www.elemental.co.za
http://www.wapit.co.za




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Angelo Zanetti]

-Original Message-
From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
Sent: 20 August 2009 02:58 PM
To: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

On Thu, Aug 20, 2009 at 02:34:54PM +0200, Angelo Zanetti wrote:
> Hi Leon, 
> 
> No harm intended :) Just thought that people were missing my post now and
> only answering yours.
> 

Angelo, excuse me if I'm bringing up something very basic, but I'm new
to this.  Just trying to help.  

I imagine redirects couldn't be the cause of the problem, right?  

http://www.oscarm.org/news/detail/1877-avoiding_frustration_with_php_session
s

http://www.webmasterworld.com/forum88/8486.htm


Hi thanks for the links it appears that its all in order also I'm not losing
SESSIONS on the redirect but somewhere else.

I have checked the garbage collection, disk space and other settings in the
PHP.ini file. ALL FINE.

So now I am really stuck and confused as to what could sometimes cause the
loss of these variables and other times it just works fine. 

Is there possibly a way that I can call some function that will ensure that
the sessions are saved (I checked the manual - nothing much).

Any other ideas? Anything that you think might be causing issues? 

Thanks
Angelo



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[kranthi]

>> I imagine redirects couldn't be the cause of the problem, right?
Thanks, this is really a life saver.. I never used
session_write_close() before any redirects...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Ashley Sheridan]

On Thu, 2009-08-20 at 18:38 +0530, kranthi wrote:
> The original problem..
> 
> >> server is losing session variables.
> I dont think PHP is not good at unset() ing variables while the script
> is executing.
> 
> general logger will be of use in this case (especially when cant
> reproduce the problem every time). PEAR, Zend, FirePHP, files... any
> thing will do...
> 
> try to log every thing related to sessions at the start of the page...
> session_id, $_SESSION super global, _SERVER['PHP_SELF']
> do the same thing after the script exists...
> 
> i had a similar problem earlier...
> a page in my app used to change $_SESSION['id']. It took me ages to
> find out the source... even grep was of no use... at last  i was able
> to isolate the page that was causing this, with the help of logging.
> Of course, the main problem was that my production server has
> register_globals on, while my development server has them off.
> 
Register globals is really not a good thing to use for modern setups. It
makes it a little easier for people to exploit holes in weaker PHP
scripts.


Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[kranthi]

The original problem..

>> server is losing session variables.
I dont think PHP is not good at unset() ing variables while the script
is executing.

general logger will be of use in this case (especially when cant
reproduce the problem every time). PEAR, Zend, FirePHP, files... any
thing will do...

try to log every thing related to sessions at the start of the page...
session_id, $_SESSION super global, _SERVER['PHP_SELF']
do the same thing after the script exists...

i had a similar problem earlier...
a page in my app used to change $_SESSION['id']. It took me ages to
find out the source... even grep was of no use... at last  i was able
to isolate the page that was causing this, with the help of logging.
Of course, the main problem was that my production server has
register_globals on, while my development server has them off.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Nitebirdz]

On Thu, Aug 20, 2009 at 02:34:54PM +0200, Angelo Zanetti wrote:
> Hi Leon, 
> 
> No harm intended :) Just thought that people were missing my post now and
> only answering yours.
> 

Angelo, excuse me if I'm bringing up something very basic, but I'm new
to this.  Just trying to help.  

I imagine redirects couldn't be the cause of the problem, right?  

http://www.oscarm.org/news/detail/1877-avoiding_frustration_with_php_sessions

http://www.webmasterworld.com/forum88/8486.htm



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

No problem! Thx

-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 20 August 2009 02:35 PM
To: 'Leon du Plessis'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Leon, 

No harm intended :) Just thought that people were missing my post now and
only answering yours.

Anyways hope your issue got resolved.

Angelo


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 01:46 PM
To: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Angelo, 

No need to be nasty and touchy. If you have done trouble to read I have
closed the discussion in a prior listing and referred back to your original
thread. thanks

-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 20 August 2009 01:21 PM
To: 'Leon du Plessis'; a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Leon and all.

LEON you are misunderstanding how the sessions work. Also please start your
own thread and don't hijack mine.

To the rest that replied. Thanks, I am still stuck with the problem I have
asked the hosting company to check the storage capacity and also any other
issues with the SESSIONS on the server.

However if anyone has other things they think I can look at, I'd appreciate
that very much.

Thanks
Angelo
http://www.elemental.co.za


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 12:04 PM
To: a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Thanks Ashley, 

I just want to iterate again that when a new page is opened by another
existing page in a new browser or Tab, the session_id is already created and
therefore the current way browsers work is in no way compremised. The new
browser/tab would receive the session id along with GET or POST variables.

What I am suggesting/hoping is that when a new browser is opened or a new
tab is opened via the application, the protocols would reckognize that this
is the first time the page is served and is not being called from another
page. That is, a new page is loaded by the user entering it, and NOT by
clicking login or some other link from an existing page.

Yes, I know..that creates other scenarios, so is happy to not meddle with
the way browsers work. It is just a limitation I will live with and can get
by with it.

Regards
Leon

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 11:39 AM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The
problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not
affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including t

RE: [PHP] SESSIONS lost sometimes

[Angelo Zanetti]

Hi Leon, 

No harm intended :) Just thought that people were missing my post now and
only answering yours.

Anyways hope your issue got resolved.

Angelo


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 01:46 PM
To: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Angelo, 

No need to be nasty and touchy. If you have done trouble to read I have
closed the discussion in a prior listing and referred back to your original
thread. thanks

-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 20 August 2009 01:21 PM
To: 'Leon du Plessis'; a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Leon and all.

LEON you are misunderstanding how the sessions work. Also please start your
own thread and don't hijack mine.

To the rest that replied. Thanks, I am still stuck with the problem I have
asked the hosting company to check the storage capacity and also any other
issues with the SESSIONS on the server.

However if anyone has other things they think I can look at, I'd appreciate
that very much.

Thanks
Angelo
http://www.elemental.co.za


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 12:04 PM
To: a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Thanks Ashley, 

I just want to iterate again that when a new page is opened by another
existing page in a new browser or Tab, the session_id is already created and
therefore the current way browsers work is in no way compremised. The new
browser/tab would receive the session id along with GET or POST variables.

What I am suggesting/hoping is that when a new browser is opened or a new
tab is opened via the application, the protocols would reckognize that this
is the first time the page is served and is not being called from another
page. That is, a new page is loaded by the user entering it, and NOT by
clicking login or some other link from an existing page.

Yes, I know..that creates other scenarios, so is happy to not meddle with
the way browsers work. It is just a limitation I will live with and can get
by with it.

Regards
Leon

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 11:39 AM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The
problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not
affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including the likes of Google Mail, etc.  When
> I want to run multiple sessions for different GMail accounts, for
> example, I just create a different user profile in Firefox. 
> 
> It'd make sense for things to run thi

Re: [PHP] SESSIONS lost sometimes

[Floyd Resler]

Leon,
	Sessions are used on a per-domain basis.  So, no matter how many  
windows or tabs you have open for mydomain.com it will be the same  
session for all.  Having a different session start up for each window  
or tab would be a major pain.  If you needed to keep track of a user  
ID, for example, you wouldn't be able to.  As already mentioned you  
can use different browsers.  You can also set up sub-domains which  
would each have their own sessions.


Take care,
Floyd

On Aug 20, 2009, at 4:26 AM, Leon du Plessis wrote:


">> It's not an issue, it's a feature."

Thanks Arno...but it is a pain also.
If I work with user A in Tab1 (window1), I want to work with user B
separately in Tab2. When user in Tab2 logs off, I still want user A  
to work,
and not suddenly have to re-login. Same with bank. If I work with my  
company
account, then my personal account must not become an issue because I  
am on

the same machine and site.

I have no issue with using FF and IE to do testing as that takes  
care of
browser compatibility testing at the same time :-), but I think when  
you
start a new session with new values, it should be kept under that  
window/tab
alone. Cookies can take care of more details, but my opinion is data  
should
never be affected across windows/tabs unless the same user is logged  
in on
botheven then I would expect PHP to keep data per session. Maybe  
it goes
beyond being an IE or FF issue..the questiojn is...will PHP allow  
variables
from session A become corrupted when session B is in progress when  
they

should actually be handled seperately?

In the end I think it is something I do wrong in PHP with the SESSION
variables and how I clear themif so...I don't think PHP should  
allow

clearing SESSION variables from other sessions.

-Original Message-
From: Arno Kuhl [mailto:ak...@telkomsa.net]
Sent: 20 August 2009 10:03 AM
To: 'Leon du Plessis'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com]
Sent: 20 August 2009 09:44 AM
To: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Since we are on the subject: I have the following similar problem:

When testing page on internet explorer, I find that one tab's  
variables can
affect another tab's variables. Thus when having the same web-site  
open and

using SESSION variables but for different users, Internet explorer can
become "disorientated". This also "sometimes" happen when I have two
separate browsing windows open with Internet Explorer for the same  
site.


I have yet to determine if this is an internet explorer, or PHP or
combination of the two that is causing this condition.

To my understanding _SESSION variables should be maintained per  
session, tab
or window. If this has been addressed already, my apologies, but  
thought it

worthwhile to mention.

If someone perhaps have a solution or can confirm this as a known  
issue and

maybe is the same or related to Angelo's problem?



If different browser windows/tabs on the same client-side computer  
didn't
share session info then you'd get the effect of being able to log  
onto a
site with one browser window, but find in a second browser window  
that you
were not yet logged on. Experience will tell you that you're logged  
on in
both browser windows (try it with your online bank). It's not an  
issue, it's
a feature. If you want to be able to use different browser windows  
as though
they were different users then use different browsers e.g. IE and FF  
on the

same client-side computer will look like two separate end users to the
server, and they don't share session info or cookies.

Cheers
Arno


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

Hi Angelo, 

No need to be nasty and touchy. If you have done trouble to read I have
closed the discussion in a prior listing and referred back to your original
thread. thanks

-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 20 August 2009 01:21 PM
To: 'Leon du Plessis'; a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Hi Leon and all.

LEON you are misunderstanding how the sessions work. Also please start your
own thread and don't hijack mine.

To the rest that replied. Thanks, I am still stuck with the problem I have
asked the hosting company to check the storage capacity and also any other
issues with the SESSIONS on the server.

However if anyone has other things they think I can look at, I'd appreciate
that very much.

Thanks
Angelo
http://www.elemental.co.za


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 12:04 PM
To: a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Thanks Ashley, 

I just want to iterate again that when a new page is opened by another
existing page in a new browser or Tab, the session_id is already created and
therefore the current way browsers work is in no way compremised. The new
browser/tab would receive the session id along with GET or POST variables.

What I am suggesting/hoping is that when a new browser is opened or a new
tab is opened via the application, the protocols would reckognize that this
is the first time the page is served and is not being called from another
page. That is, a new page is loaded by the user entering it, and NOT by
clicking login or some other link from an existing page.

Yes, I know..that creates other scenarios, so is happy to not meddle with
the way browsers work. It is just a limitation I will live with and can get
by with it.

Regards
Leon

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 11:39 AM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The
problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not
affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including the likes of Google Mail, etc.  When
> I want to run multiple sessions for different GMail accounts, for
> example, I just create a different user profile in Firefox. 
> 
> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
> to edit it.  
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub

Re: [PHP] SESSIONS lost sometimes

[Nitebirdz]

On Thu, Aug 20, 2009 at 12:04:08PM +0200, Leon du Plessis wrote:
> Thanks Ashley, 
> 
> I just want to iterate again that when a new page is opened by another
> existing page in a new browser or Tab, the session_id is already created and
> therefore the current way browsers work is in no way compremised. The new
> browser/tab would receive the session id along with GET or POST variables.
> 
> What I am suggesting/hoping is that when a new browser is opened or a new
> tab is opened via the application, the protocols would reckognize that this
> is the first time the page is served and is not being called from another
> page. That is, a new page is loaded by the user entering it, and NOT by
> clicking login or some other link from an existing page.
> 

Out of curiosity.  Did you test it under Google Chrome?  I believe each
tab is a separate process in the case of that browser.  I wonder how
that might affect something like this.  


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Angelo Zanetti]

Hi Leon and all.

LEON you are misunderstanding how the sessions work. Also please start your
own thread and don't hijack mine.

To the rest that replied. Thanks, I am still stuck with the problem I have
asked the hosting company to check the storage capacity and also any other
issues with the SESSIONS on the server.

However if anyone has other things they think I can look at, I'd appreciate
that very much.

Thanks
Angelo
http://www.elemental.co.za


-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 12:04 PM
To: a...@ashleysheridan.co.uk
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Thanks Ashley, 

I just want to iterate again that when a new page is opened by another
existing page in a new browser or Tab, the session_id is already created and
therefore the current way browsers work is in no way compremised. The new
browser/tab would receive the session id along with GET or POST variables.

What I am suggesting/hoping is that when a new browser is opened or a new
tab is opened via the application, the protocols would reckognize that this
is the first time the page is served and is not being called from another
page. That is, a new page is loaded by the user entering it, and NOT by
clicking login or some other link from an existing page.

Yes, I know..that creates other scenarios, so is happy to not meddle with
the way browsers work. It is just a limitation I will live with and can get
by with it.

Regards
Leon

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 11:39 AM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The
problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not
affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including the likes of Google Mail, etc.  When
> I want to run multiple sessions for different GMail accounts, for
> example, I just create a different user profile in Firefox. 
> 
> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
> to edit it.  
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
The point is you are misunderstanding how browsers work. What the server
app is seeing is a new login that replaces the first. This is the way
browsers work, and if it changed to the idea you have for it, then
millions of sites would suddenly fail to work; i.e. any site that
requires a new tab or window to be opened in order to function, like
banks, etc.

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

Thanks Ashley. Will implement if the need arise again..
By limitation I actually meant "annoyance". 
"Limitation" was the wrong word to use.
(I think all browsers has something great and something not so great)

:-)
Greetings

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 12:05 PM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 12:04 +0200, Leon du Plessis wrote:
> Thanks Ashley, 
> 
> I just want to iterate again that when a new page is opened by another
> existing page in a new browser or Tab, the session_id is already created
and
> therefore the current way browsers work is in no way compremised. The new
> browser/tab would receive the session id along with GET or POST variables.
> 
> What I am suggesting/hoping is that when a new browser is opened or a new
> tab is opened via the application, the protocols would reckognize that
this
> is the first time the page is served and is not being called from another
> page. That is, a new page is loaded by the user entering it, and NOT by
> clicking login or some other link from an existing page.
> 
> Yes, I know..that creates other scenarios, so is happy to not meddle with
> the way browsers work. It is just a limitation I will live with and can
get
> by with it.
> 
> Regards
> Leon
> 
> -Original Message-
> From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
> Sent: 20 August 2009 11:39 AM
> To: Leon du Plessis
> Cc: 'Nitebirdz'; php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> > ">> It'd make sense for things to run this way, I think.  After all, I'd
> > find it quite confusing if I log into Google Docs, open a document (by
> > default, it opens in a new tab) and I had to log in yet again to be able
> to
> > edit it."
> > 
> > Yes. I agree. But in this case the Tab being opened is used with the
same
> > authentication details either via POST, GET or Cookie variables. The
> problem
> > comes in when a totally different set of login credentials are being
used
> > (for the same tab/window).  Other user's login particulars should not
> affect
> > your login variables.
> > 
> > -Original Message-
> > From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> > Sent: 20 August 2009 10:40 AM
> > To: php-general@lists.php.net
> > Subject: Re: [PHP] SESSIONS lost sometimes
> > 
> > On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > > 
> > > Since we are on the subject: I have the following similar problem:
> > > 
> > > When testing page on internet explorer, I find that one tab's
variables
> > can
> > > affect another tab's variables. Thus when having the same web-site
open
> > and
> > > using SESSION variables but for different users, Internet explorer can
> > > become "disorientated". This also "sometimes" happen when I have two
> > > separate browsing windows open with Internet Explorer for the same
site.
> > > 
> > > I have yet to determine if this is an internet explorer, or PHP or
> > > combination of the two that is causing this condition. 
> > > 
> > > To my understanding _SESSION variables should be maintained per
session,
> > tab
> > > or window. If this has been addressed already, my apologies, but
thought
> > it
> > > worthwhile to mention.  
> > > 
> > 
> > I'm a total newbie when it comes to these issues, but it seems to me
> > that Firefox behaves in the very same manner.  It's not limited to PHP
> > sessions either.  It's always been my experience on any website that
> > requires authentication, including the likes of Google Mail, etc.  When
> > I want to run multiple sessions for different GMail accounts, for
> > example, I just create a different user profile in Firefox. 
> > 
> > It'd make sense for things to run this way, I think.  After all, I'd
> > find it quite confusing if I log into Google Docs, open a document (by
> > default, it opens in a new tab) and I had to log in yet again to be able
> > to edit it.  
> > 
> > 
> > -- 
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> The point is you are misunderstanding how browsers work. What the server
> app is seeing is a new login that replaces the first. This is t

RE: [PHP] SESSIONS lost sometimes

[Ashley Sheridan]

On Thu, 2009-08-20 at 12:04 +0200, Leon du Plessis wrote:
> Thanks Ashley, 
> 
> I just want to iterate again that when a new page is opened by another
> existing page in a new browser or Tab, the session_id is already created and
> therefore the current way browsers work is in no way compremised. The new
> browser/tab would receive the session id along with GET or POST variables.
> 
> What I am suggesting/hoping is that when a new browser is opened or a new
> tab is opened via the application, the protocols would reckognize that this
> is the first time the page is served and is not being called from another
> page. That is, a new page is loaded by the user entering it, and NOT by
> clicking login or some other link from an existing page.
> 
> Yes, I know..that creates other scenarios, so is happy to not meddle with
> the way browsers work. It is just a limitation I will live with and can get
> by with it.
> 
> Regards
> Leon
> 
> -Original Message-
> From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
> Sent: 20 August 2009 11:39 AM
> To: Leon du Plessis
> Cc: 'Nitebirdz'; php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> > ">> It'd make sense for things to run this way, I think.  After all, I'd
> > find it quite confusing if I log into Google Docs, open a document (by
> > default, it opens in a new tab) and I had to log in yet again to be able
> to
> > edit it."
> > 
> > Yes. I agree. But in this case the Tab being opened is used with the same
> > authentication details either via POST, GET or Cookie variables. The
> problem
> > comes in when a totally different set of login credentials are being used
> > (for the same tab/window).  Other user's login particulars should not
> affect
> > your login variables.
> > 
> > -Original Message-
> > From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> > Sent: 20 August 2009 10:40 AM
> > To: php-general@lists.php.net
> > Subject: Re: [PHP] SESSIONS lost sometimes
> > 
> > On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > > 
> > > Since we are on the subject: I have the following similar problem:
> > > 
> > > When testing page on internet explorer, I find that one tab's variables
> > can
> > > affect another tab's variables. Thus when having the same web-site open
> > and
> > > using SESSION variables but for different users, Internet explorer can
> > > become "disorientated". This also "sometimes" happen when I have two
> > > separate browsing windows open with Internet Explorer for the same site.
> > > 
> > > I have yet to determine if this is an internet explorer, or PHP or
> > > combination of the two that is causing this condition. 
> > > 
> > > To my understanding _SESSION variables should be maintained per session,
> > tab
> > > or window. If this has been addressed already, my apologies, but thought
> > it
> > > worthwhile to mention.  
> > > 
> > 
> > I'm a total newbie when it comes to these issues, but it seems to me
> > that Firefox behaves in the very same manner.  It's not limited to PHP
> > sessions either.  It's always been my experience on any website that
> > requires authentication, including the likes of Google Mail, etc.  When
> > I want to run multiple sessions for different GMail accounts, for
> > example, I just create a different user profile in Firefox. 
> > 
> > It'd make sense for things to run this way, I think.  After all, I'd
> > find it quite confusing if I log into Google Docs, open a document (by
> > default, it opens in a new tab) and I had to log in yet again to be able
> > to edit it.  
> > 
> > 
> > -- 
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> The point is you are misunderstanding how browsers work. What the server
> app is seeing is a new login that replaces the first. This is the way
> browsers work, and if it changed to the idea you have for it, then
> millions of sites would suddenly fail to work; i.e. any site that
> requires a new tab or window to be opened in order to function, like
> banks, etc.
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
There is one way to get around it, and that is to use arrays within your
session variables. So for example, it might look something like this:

$_SESSION['your_app_name']['username']['some_value']

This way, if the username doesn't exist, you know there is no session
for them. It's ugly, but it will get around what you see as a
limitation.

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

Thanks Ashley, 

I just want to iterate again that when a new page is opened by another
existing page in a new browser or Tab, the session_id is already created and
therefore the current way browsers work is in no way compremised. The new
browser/tab would receive the session id along with GET or POST variables.

What I am suggesting/hoping is that when a new browser is opened or a new
tab is opened via the application, the protocols would reckognize that this
is the first time the page is served and is not being called from another
page. That is, a new page is loaded by the user entering it, and NOT by
clicking login or some other link from an existing page.

Yes, I know..that creates other scenarios, so is happy to not meddle with
the way browsers work. It is just a limitation I will live with and can get
by with it.

Regards
Leon

-Original Message-
From: Ashley Sheridan [mailto:a...@ashleysheridan.co.uk] 
Sent: 20 August 2009 11:39 AM
To: Leon du Plessis
Cc: 'Nitebirdz'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The
problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not
affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including the likes of Google Mail, etc.  When
> I want to run multiple sessions for different GMail accounts, for
> example, I just create a different user profile in Firefox. 
> 
> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
> to edit it.  
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
The point is you are misunderstanding how browsers work. What the server
app is seeing is a new login that replaces the first. This is the way
browsers work, and if it changed to the idea you have for it, then
millions of sites would suddenly fail to work; i.e. any site that
requires a new tab or window to be opened in order to function, like
banks, etc.

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Ashley Sheridan]

On Thu, 2009-08-20 at 10:50 +0200, Leon du Plessis wrote:
> ">> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able to
> edit it."
> 
> Yes. I agree. But in this case the Tab being opened is used with the same
> authentication details either via POST, GET or Cookie variables. The problem
> comes in when a totally different set of login credentials are being used
> (for the same tab/window).  Other user's login particulars should not affect
> your login variables.
> 
> -Original Message-
> From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
> Sent: 20 August 2009 10:40 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] SESSIONS lost sometimes
> 
> On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> > 
> > Since we are on the subject: I have the following similar problem:
> > 
> > When testing page on internet explorer, I find that one tab's variables
> can
> > affect another tab's variables. Thus when having the same web-site open
> and
> > using SESSION variables but for different users, Internet explorer can
> > become "disorientated". This also "sometimes" happen when I have two
> > separate browsing windows open with Internet Explorer for the same site.
> > 
> > I have yet to determine if this is an internet explorer, or PHP or
> > combination of the two that is causing this condition. 
> > 
> > To my understanding _SESSION variables should be maintained per session,
> tab
> > or window. If this has been addressed already, my apologies, but thought
> it
> > worthwhile to mention.  
> > 
> 
> I'm a total newbie when it comes to these issues, but it seems to me
> that Firefox behaves in the very same manner.  It's not limited to PHP
> sessions either.  It's always been my experience on any website that
> requires authentication, including the likes of Google Mail, etc.  When
> I want to run multiple sessions for different GMail accounts, for
> example, I just create a different user profile in Firefox. 
> 
> It'd make sense for things to run this way, I think.  After all, I'd
> find it quite confusing if I log into Google Docs, open a document (by
> default, it opens in a new tab) and I had to log in yet again to be able
> to edit it.  
> 
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
The point is you are misunderstanding how browsers work. What the server
app is seeing is a new login that replaces the first. This is the way
browsers work, and if it changed to the idea you have for it, then
millions of sites would suddenly fail to work; i.e. any site that
requires a new tab or window to be opened in order to function, like
banks, etc.

Thanks,
Ash
http://www.ashleysheridan.co.uk




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

Hi, 

Just a re-iteration on the problem:

Browser 1 has user A details 

Browser 2 has user B details

User B logs off, then user A is suddenly in logged of status also.

The method used to destroy the session is:
// Unset all of the session variables.
$_SESSION = array();

// Finally, destroy the session.
session_destroy();

Problem. User's A session is also destroyed. The concern is, that this
should not be the case. User A must happily continue to work.

So, should PHP destroy the whole browser's session id's variables? My answer
is "No".

User A and user B should have different session ids, if not, then it is
wrong. A new window should have PHP to spawn a new session id (that is, the
request does not come from an existing page where an id has been created
already. If the ids are different, then session_destroy should only clear
variables for relevant session_id, ie only User B's details In this example.


The problem then probably lies in the session_ids being either the same for
the two different logins (although they are on different browser) or
session_destroy clearing data across sessions. (I will test that later). It
would then seem that session ids is setup per location/machine by MS Windows
as per Peter's explanation. Setting up profiles is the the resolution as
suggested. Otherwise, it would be nice if Windows/IE/FF/PHP could identify
when a BRAND NEW page is being opened and then create a brand new session id
for that window/tab.

It is not a huge issue, I was just wondering if someone else had the same
annoying condition. I am happy with the responses and the functionality
somewhere on a wish-list. 

Now Back to Angelo's SESSION problem which sounded like it could be related.

Greetings!
Leon

-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 10:57 AM
To: 'Peter Ford'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes



That is how I know browsers to work, yet for a while the bahaviour has
changed. The question in light of this then is, should a new browser or tab
not open a new PHP SESSION ID. Session ID's should be kept if called from
existing pages or ID's? But new pages has no parent? Just wondering.

-Original Message-
From: Peter Ford [mailto:p...@justcroft.com] 
Sent: 20 August 2009 10:47 AM
To: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

Leon du Plessis wrote:
> ">> It's not an issue, it's a feature."
> 
> Thanks Arno...but it is a pain also.
> If I work with user A in Tab1 (window1), I want to work with user B
> separately in Tab2. When user in Tab2 logs off, I still want user A to
work,
> and not suddenly have to re-login. Same with bank. If I work with my
company
> account, then my personal account must not become an issue because I am on
> the same machine and site. 
> 
> I have no issue with using FF and IE to do testing as that takes care of
> browser compatibility testing at the same time :-), but I think when you
> start a new session with new values, it should be kept under that
window/tab
> alone. Cookies can take care of more details, but my opinion is data
should
> never be affected across windows/tabs unless the same user is logged in on
> botheven then I would expect PHP to keep data per session. Maybe it
goes
> beyond being an IE or FF issue..the questiojn is...will PHP allow
variables
> from session A become corrupted when session B is in progress when they
> should actually be handled seperately?
> 
> In the end I think it is something I do wrong in PHP with the SESSION
> variables and how I clear themif so...I don't think PHP should allow
> clearing SESSION variables from other sessions.
>  
> -Original Message-----
> From: Arno Kuhl [mailto:ak...@telkomsa.net] 
> Sent: 20 August 2009 10:03 AM
> To: 'Leon du Plessis'; php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> -Original Message-
> From: Leon du Plessis [mailto:l...@dsgnit.com] 
> Sent: 20 August 2009 09:44 AM
> To: php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> Since we are on the subject: I have the following similar problem:
> 
> When testing page on internet explorer, I find that one tab's variables
can
> affect another tab's variables. Thus when having the same web-site open
and
> using SESSION variables but for different users, Internet explorer can
> become "disorientated". This also "sometimes" happen when I have two
> separate browsing windows open with Internet Explorer for the same site.
> 
> I have yet to determine if this is an internet explorer, or PHP or
> combination of the two that is causing this condition. 
> 
> To my understanding _SESSION vari

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

That is how I know browsers to work, yet for a while the bahaviour has
changed. The question in light of this then is, should a new browser or tab
not open a new PHP SESSION ID. Session ID's should be kept if called from
existing pages or ID's? But new pages has no parent? Just wondering.

-Original Message-
From: Peter Ford [mailto:p...@justcroft.com] 
Sent: 20 August 2009 10:47 AM
To: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

Leon du Plessis wrote:
> ">> It's not an issue, it's a feature."
> 
> Thanks Arno...but it is a pain also.
> If I work with user A in Tab1 (window1), I want to work with user B
> separately in Tab2. When user in Tab2 logs off, I still want user A to
work,
> and not suddenly have to re-login. Same with bank. If I work with my
company
> account, then my personal account must not become an issue because I am on
> the same machine and site. 
> 
> I have no issue with using FF and IE to do testing as that takes care of
> browser compatibility testing at the same time :-), but I think when you
> start a new session with new values, it should be kept under that
window/tab
> alone. Cookies can take care of more details, but my opinion is data
should
> never be affected across windows/tabs unless the same user is logged in on
> botheven then I would expect PHP to keep data per session. Maybe it
goes
> beyond being an IE or FF issue..the questiojn is...will PHP allow
variables
> from session A become corrupted when session B is in progress when they
> should actually be handled seperately?
> 
> In the end I think it is something I do wrong in PHP with the SESSION
> variables and how I clear themif so...I don't think PHP should allow
> clearing SESSION variables from other sessions.
>  
> -Original Message-
> From: Arno Kuhl [mailto:ak...@telkomsa.net] 
> Sent: 20 August 2009 10:03 AM
> To: 'Leon du Plessis'; php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> -Original Message-
> From: Leon du Plessis [mailto:l...@dsgnit.com] 
> Sent: 20 August 2009 09:44 AM
> To: php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> Since we are on the subject: I have the following similar problem:
> 
> When testing page on internet explorer, I find that one tab's variables
can
> affect another tab's variables. Thus when having the same web-site open
and
> using SESSION variables but for different users, Internet explorer can
> become "disorientated". This also "sometimes" happen when I have two
> separate browsing windows open with Internet Explorer for the same site.
> 
> I have yet to determine if this is an internet explorer, or PHP or
> combination of the two that is causing this condition. 
> 
> To my understanding _SESSION variables should be maintained per session,
tab
> or window. If this has been addressed already, my apologies, but thought
it
> worthwhile to mention.  
> 
> If someone perhaps have a solution or can confirm this as a known issue
and
> maybe is the same or related to Angelo's problem?
> 
> 
> 
> If different browser windows/tabs on the same client-side computer didn't
> share session info then you'd get the effect of being able to log onto a
> site with one browser window, but find in a second browser window that you
> were not yet logged on. Experience will tell you that you're logged on in
> both browser windows (try it with your online bank). It's not an issue,
it's
> a feature. If you want to be able to use different browser windows as
though
> they were different users then use different browsers e.g. IE and FF on
the
> same client-side computer will look like two separate end users to the
> server, and they don't share session info or cookies.
> 
> Cheers
> Arno
> 
> 

The key thing is that both tabs (or windows) from the same browser are in
the
*same* session - they send the *same* PHPID cookie. PHP is essentially
stateless
- it doesn't care where the request comes from, and ties a session to the
PHPID
cookie if it gets one. As far as PHP knows, requests from different tabs
with
the same PHPID cookie are requests from the same place in the same session.

To get a different session you need a different instance of the browser -
that's
the way browsers have been coded to work. It's not too hard with Firefox,
since
you can set up multiple profiles to have independent Firefox windows on the
same
screen.

-- 
Peter Ford  phone: 01580 89
Developer   fax:   01580 893399
Justcroft International Ltd., Staplehurst, Kent

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

">> It'd make sense for things to run this way, I think.  After all, I'd
find it quite confusing if I log into Google Docs, open a document (by
default, it opens in a new tab) and I had to log in yet again to be able to
edit it."

Yes. I agree. But in this case the Tab being opened is used with the same
authentication details either via POST, GET or Cookie variables. The problem
comes in when a totally different set of login credentials are being used
(for the same tab/window).  Other user's login particulars should not affect
your login variables.

-Original Message-
From: Nitebirdz [mailto:nitebi...@sacredchaos.com] 
Sent: 20 August 2009 10:40 AM
To: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> 
> Since we are on the subject: I have the following similar problem:
> 
> When testing page on internet explorer, I find that one tab's variables
can
> affect another tab's variables. Thus when having the same web-site open
and
> using SESSION variables but for different users, Internet explorer can
> become "disorientated". This also "sometimes" happen when I have two
> separate browsing windows open with Internet Explorer for the same site.
> 
> I have yet to determine if this is an internet explorer, or PHP or
> combination of the two that is causing this condition. 
> 
> To my understanding _SESSION variables should be maintained per session,
tab
> or window. If this has been addressed already, my apologies, but thought
it
> worthwhile to mention.  
> 

I'm a total newbie when it comes to these issues, but it seems to me
that Firefox behaves in the very same manner.  It's not limited to PHP
sessions either.  It's always been my experience on any website that
requires authentication, including the likes of Google Mail, etc.  When
I want to run multiple sessions for different GMail accounts, for
example, I just create a different user profile in Firefox. 

It'd make sense for things to run this way, I think.  After all, I'd
find it quite confusing if I log into Google Docs, open a document (by
default, it opens in a new tab) and I had to log in yet again to be able
to edit it.  


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Nitebirdz]

On Thu, Aug 20, 2009 at 10:26:35AM +0200, Leon du Plessis wrote:
> ">> It's not an issue, it's a feature."
> 
> Thanks Arno...but it is a pain also.
> If I work with user A in Tab1 (window1), I want to work with user B
> separately in Tab2. When user in Tab2 logs off, I still want user A to work,
> and not suddenly have to re-login. Same with bank. If I work with my company
> account, then my personal account must not become an issue because I am on
> the same machine and site. 
> 

As mentioned in my other email, I've only been able to get this to work
by using different user profiles under Firefox.  If you need to run them
both at the same time, the following document helps explaining how to
accomplish it:

http://lifehacker.com/software/firefox/geek-to-live--manage-multiple-firefox-profiles-231646.php


I never tested it because I don't run Windows, but a similar setup works
just fine for Linux. 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Peter Ford]

Leon du Plessis wrote:
> ">> It's not an issue, it's a feature."
> 
> Thanks Arno...but it is a pain also.
> If I work with user A in Tab1 (window1), I want to work with user B
> separately in Tab2. When user in Tab2 logs off, I still want user A to work,
> and not suddenly have to re-login. Same with bank. If I work with my company
> account, then my personal account must not become an issue because I am on
> the same machine and site. 
> 
> I have no issue with using FF and IE to do testing as that takes care of
> browser compatibility testing at the same time :-), but I think when you
> start a new session with new values, it should be kept under that window/tab
> alone. Cookies can take care of more details, but my opinion is data should
> never be affected across windows/tabs unless the same user is logged in on
> botheven then I would expect PHP to keep data per session. Maybe it goes
> beyond being an IE or FF issue..the questiojn is...will PHP allow variables
> from session A become corrupted when session B is in progress when they
> should actually be handled seperately?
> 
> In the end I think it is something I do wrong in PHP with the SESSION
> variables and how I clear themif so...I don't think PHP should allow
> clearing SESSION variables from other sessions.
>  
> -Original Message-
> From: Arno Kuhl [mailto:ak...@telkomsa.net] 
> Sent: 20 August 2009 10:03 AM
> To: 'Leon du Plessis'; php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> -Original Message-----
> From: Leon du Plessis [mailto:l...@dsgnit.com] 
> Sent: 20 August 2009 09:44 AM
> To: php-general@lists.php.net
> Subject: RE: [PHP] SESSIONS lost sometimes
> 
> Since we are on the subject: I have the following similar problem:
> 
> When testing page on internet explorer, I find that one tab's variables can
> affect another tab's variables. Thus when having the same web-site open and
> using SESSION variables but for different users, Internet explorer can
> become "disorientated". This also "sometimes" happen when I have two
> separate browsing windows open with Internet Explorer for the same site.
> 
> I have yet to determine if this is an internet explorer, or PHP or
> combination of the two that is causing this condition. 
> 
> To my understanding _SESSION variables should be maintained per session, tab
> or window. If this has been addressed already, my apologies, but thought it
> worthwhile to mention.  
> 
> If someone perhaps have a solution or can confirm this as a known issue and
> maybe is the same or related to Angelo's problem?
> 
> 
> 
> If different browser windows/tabs on the same client-side computer didn't
> share session info then you'd get the effect of being able to log onto a
> site with one browser window, but find in a second browser window that you
> were not yet logged on. Experience will tell you that you're logged on in
> both browser windows (try it with your online bank). It's not an issue, it's
> a feature. If you want to be able to use different browser windows as though
> they were different users then use different browsers e.g. IE and FF on the
> same client-side computer will look like two separate end users to the
> server, and they don't share session info or cookies.
> 
> Cheers
> Arno
> 
> 

The key thing is that both tabs (or windows) from the same browser are in the
*same* session - they send the *same* PHPID cookie. PHP is essentially stateless
- it doesn't care where the request comes from, and ties a session to the PHPID
cookie if it gets one. As far as PHP knows, requests from different tabs with
the same PHPID cookie are requests from the same place in the same session.

To get a different session you need a different instance of the browser - that's
the way browsers have been coded to work. It's not too hard with Firefox, since
you can set up multiple profiles to have independent Firefox windows on the same
screen.

-- 
Peter Ford  phone: 01580 89
Developer   fax:   01580 893399
Justcroft International Ltd., Staplehurst, Kent

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Nitebirdz]

On Thu, Aug 20, 2009 at 09:44:02AM +0200, Leon du Plessis wrote:
> 
> Since we are on the subject: I have the following similar problem:
> 
> When testing page on internet explorer, I find that one tab's variables can
> affect another tab's variables. Thus when having the same web-site open and
> using SESSION variables but for different users, Internet explorer can
> become "disorientated". This also "sometimes" happen when I have two
> separate browsing windows open with Internet Explorer for the same site.
> 
> I have yet to determine if this is an internet explorer, or PHP or
> combination of the two that is causing this condition. 
> 
> To my understanding _SESSION variables should be maintained per session, tab
> or window. If this has been addressed already, my apologies, but thought it
> worthwhile to mention.  
> 

I'm a total newbie when it comes to these issues, but it seems to me
that Firefox behaves in the very same manner.  It's not limited to PHP
sessions either.  It's always been my experience on any website that
requires authentication, including the likes of Google Mail, etc.  When
I want to run multiple sessions for different GMail accounts, for
example, I just create a different user profile in Firefox. 

It'd make sense for things to run this way, I think.  After all, I'd
find it quite confusing if I log into Google Docs, open a document (by
default, it opens in a new tab) and I had to log in yet again to be able
to edit it.  


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

">> It's not an issue, it's a feature."

Thanks Arno...but it is a pain also.
If I work with user A in Tab1 (window1), I want to work with user B
separately in Tab2. When user in Tab2 logs off, I still want user A to work,
and not suddenly have to re-login. Same with bank. If I work with my company
account, then my personal account must not become an issue because I am on
the same machine and site. 

I have no issue with using FF and IE to do testing as that takes care of
browser compatibility testing at the same time :-), but I think when you
start a new session with new values, it should be kept under that window/tab
alone. Cookies can take care of more details, but my opinion is data should
never be affected across windows/tabs unless the same user is logged in on
botheven then I would expect PHP to keep data per session. Maybe it goes
beyond being an IE or FF issue..the questiojn is...will PHP allow variables
from session A become corrupted when session B is in progress when they
should actually be handled seperately?

In the end I think it is something I do wrong in PHP with the SESSION
variables and how I clear themif so...I don't think PHP should allow
clearing SESSION variables from other sessions.
 
-Original Message-
From: Arno Kuhl [mailto:ak...@telkomsa.net] 
Sent: 20 August 2009 10:03 AM
To: 'Leon du Plessis'; php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 09:44 AM
To: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Since we are on the subject: I have the following similar problem:

When testing page on internet explorer, I find that one tab's variables can
affect another tab's variables. Thus when having the same web-site open and
using SESSION variables but for different users, Internet explorer can
become "disorientated". This also "sometimes" happen when I have two
separate browsing windows open with Internet Explorer for the same site.

I have yet to determine if this is an internet explorer, or PHP or
combination of the two that is causing this condition. 

To my understanding _SESSION variables should be maintained per session, tab
or window. If this has been addressed already, my apologies, but thought it
worthwhile to mention.  

If someone perhaps have a solution or can confirm this as a known issue and
maybe is the same or related to Angelo's problem?



If different browser windows/tabs on the same client-side computer didn't
share session info then you'd get the effect of being able to log onto a
site with one browser window, but find in a second browser window that you
were not yet logged on. Experience will tell you that you're logged on in
both browser windows (try it with your online bank). It's not an issue, it's
a feature. If you want to be able to use different browser windows as though
they were different users then use different browsers e.g. IE and FF on the
same client-side computer will look like two separate end users to the
server, and they don't share session info or cookies.

Cheers
Arno


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Arno Kuhl]

-Original Message-
From: Leon du Plessis [mailto:l...@dsgnit.com] 
Sent: 20 August 2009 09:44 AM
To: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes

Since we are on the subject: I have the following similar problem:

When testing page on internet explorer, I find that one tab's variables can
affect another tab's variables. Thus when having the same web-site open and
using SESSION variables but for different users, Internet explorer can
become "disorientated". This also "sometimes" happen when I have two
separate browsing windows open with Internet Explorer for the same site.

I have yet to determine if this is an internet explorer, or PHP or
combination of the two that is causing this condition. 

To my understanding _SESSION variables should be maintained per session, tab
or window. If this has been addressed already, my apologies, but thought it
worthwhile to mention.  

If someone perhaps have a solution or can confirm this as a known issue and
maybe is the same or related to Angelo's problem?



If different browser windows/tabs on the same client-side computer didn't
share session info then you'd get the effect of being able to log onto a
site with one browser window, but find in a second browser window that you
were not yet logged on. Experience will tell you that you're logged on in
both browser windows (try it with your online bank). It's not an issue, it's
a feature. If you want to be able to use different browser windows as though
they were different users then use different browsers e.g. IE and FF on the
same client-side computer will look like two separate end users to the
server, and they don't share session info or cookies.

Cheers
Arno


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Leon du Plessis]

Since we are on the subject: I have the following similar problem:

When testing page on internet explorer, I find that one tab's variables can
affect another tab's variables. Thus when having the same web-site open and
using SESSION variables but for different users, Internet explorer can
become "disorientated". This also "sometimes" happen when I have two
separate browsing windows open with Internet Explorer for the same site.

I have yet to determine if this is an internet explorer, or PHP or
combination of the two that is causing this condition. 

To my understanding _SESSION variables should be maintained per session, tab
or window. If this has been addressed already, my apologies, but thought it
worthwhile to mention.  

If someone perhaps have a solution or can confirm this as a known issue and
maybe is the same or related to Angelo's problem?


-Original Message-
From: Angelo Zanetti [mailto:ang...@zlogic.co.za] 
Sent: 20 August 2009 08:53 AM
To: 'Ben Dunlap'
Cc: php-general@lists.php.net
Subject: RE: [PHP] SESSIONS lost sometimes



-Original Message-
From: Ben Dunlap [mailto:bdun...@agentintellect.com] 
Sent: 19 August 2009 08:18 PM
To: Angelo Zanetti
Cc: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

> We have a server with a site that does some XML calls. After lots of
testing
> I have found that the server is losing session variables.
[8<]
> Also the site goes from HTTP to HTTPS at some point but this isn't the
issue
> as it loses the sessions as soon as they are set sometimes.
>
> Therefore I would like to know what I could check. I have read in other

Can you clarify what you mean by "losing sessions"? Have you taken a
network trace to see whether the client is consistently sending the
session ID with every request?

When the problem happens, is $_SESSION completely empty or is it only
missing some variables? Does it seem to happen on any page, or only
certain ones?

Thanks,

Ben


Hi Ben, 

When the problem happens the $_SESSION is partially empty. It only has the
some of the variables set.

It happens on a certain page only, but the strange thing is that it never
happened before its only happening now. But the code hasn't changed so is it
safe to assume that it's a server issue?

Thanks
Angelo

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] SESSIONS lost sometimes

[Angelo Zanetti]

-Original Message-
From: Ben Dunlap [mailto:bdun...@agentintellect.com] 
Sent: 19 August 2009 08:18 PM
To: Angelo Zanetti
Cc: php-general@lists.php.net
Subject: Re: [PHP] SESSIONS lost sometimes

> We have a server with a site that does some XML calls. After lots of
testing
> I have found that the server is losing session variables.
[8<]
> Also the site goes from HTTP to HTTPS at some point but this isn't the
issue
> as it loses the sessions as soon as they are set sometimes.
>
> Therefore I would like to know what I could check. I have read in other

Can you clarify what you mean by "losing sessions"? Have you taken a
network trace to see whether the client is consistently sending the
session ID with every request?

When the problem happens, is $_SESSION completely empty or is it only
missing some variables? Does it seem to happen on any page, or only
certain ones?

Thanks,

Ben


Hi Ben, 

When the problem happens the $_SESSION is partially empty. It only has the
some of the variables set.

It happens on a certain page only, but the strange thing is that it never
happened before its only happening now. But the code hasn't changed so is it
safe to assume that it's a server issue?

Thanks
Angelo

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS lost sometimes

[Ben Dunlap]

> We have a server with a site that does some XML calls. After lots of testing
> I have found that the server is losing session variables.
[8<]
> Also the site goes from HTTP to HTTPS at some point but this isn't the issue
> as it loses the sessions as soon as they are set sometimes.
>
> Therefore I would like to know what I could check. I have read in other

Can you clarify what you mean by "losing sessions"? Have you taken a
network trace to see whether the client is consistently sending the
session ID with every request?

When the problem happens, is $_SESSION completely empty or is it only
missing some variables? Does it seem to happen on any page, or only
certain ones?

Thanks,

Ben

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions

[Richard Heyes]

Hi,

> ..

This is precisely what I do, albeit my file is called config.php, and
not init.php. Not that it makes a jot of difference. This file is used
to setup the environment, so that way everything I commonly need is
available simply by including one file. One thing to note though is
that a database connection is not established by default. I used to
get a lot of comment spam on my blog and because it was needlessly
connecting to the database, it was bringing down the server. So now I
simply use something like this to quickly and easily get a reference
to a database object:

$db = getDatabase();

Wunderbar.

-- 
Richard Heyes
HTML5 graphing: RGraph (www.rgraph.net - updated 3rd July)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions

[Stuart]

2009/7/3 Ashley Sheridan :
> On Friday 03 July 2009 09:41:40 Tom Chubb wrote:
>> 2009/7/3 Luke 
>>
>> > 2009/7/3 Daniel Brown 
>> >
>> > > On Thu, Jul 2, 2009 at 23:27, Jason Carson wrote:
>> > > > Hello all,
>> > > >
>> > > > Do I have to add session_start() at the beginning of every page so
>> > > > that the $_SESSION variables work on all pages or do I use
>> > > > session_start()
>> >
>> > on
>> >
>> > > > the first page and something else on other pages?
>> > >
>> > >     Yes, unless you're using session autoloading.  Also, in most
>> > > cases, you will only need to call session_start() once (before
>> > > referencing $_SESSION), even if $_SESSION is accessed in an included
>> > > file.
>> > >
>> > > --
>> > > 
>> > > daniel.br...@parasane.net || danbr...@php.net
>> > > http://www.parasane.net/ || http://www.pilotpig.net/
>> > > Check out our hosting and dedicated server deals at
>> > > http://twitter.com/pilotpig
>> > >
>> > > --
>> > > PHP General Mailing List (http://www.php.net/)
>> > > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> > Some people have a file called init.php, which would contain
>> > session_start(); as well as other things that need to be done every page
>> > load (connect to the database perhaps?) and they just 'require' that at
>> > the top of every page.
>> >
>> > --
>> > Luke Slater
>> > http://dinosaur-os.com/
>> >
>> > :O)
>>
>> Never thought of that. Sounds like quite a good idea.
>> Can anyone tell me if there's any reason for not doing that, even on pages
>> that do not require session data?
>> Or perhaps use an htaccess file to server side include a file file to all
>> files under an admin folder or something and another to destroy the
>> session. I'm thinking of smaller, low-traffic sites.
>> I know people are going to say, if they're small sites, why can't you only
>> start sessions on the relevant pages but it sounds like it could work well
>> for me.
>
>
> It's easier to maintain if you use one include file like Luke said. You won't
> get much overhead from a call to session_start() on a page that doesn't use
> sessions.

It's also worth noting that every call to session_start() will result
in the expiry time of the session being updated. Not calling it for
pages that don't use the session could lead to the session expiring if
the user doesn't hit a page that uses it for a while.

-Stuart

-- 
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions

[Tom Chubb]

2009/7/3 Ashley Sheridan 

> On Friday 03 July 2009 09:41:40 Tom Chubb wrote:
> > 2009/7/3 Luke 
> >
> > > 2009/7/3 Daniel Brown 
> > >
> > > > On Thu, Jul 2, 2009 at 23:27, Jason Carson
> wrote:
> > > > > Hello all,
> > > > >
> > > > > Do I have to add session_start() at the beginning of every page so
> > > > > that the $_SESSION variables work on all pages or do I use
> > > > > session_start()
> > >
> > > on
> > >
> > > > > the first page and something else on other pages?
> > > >
> > > > Yes, unless you're using session autoloading.  Also, in most
> > > > cases, you will only need to call session_start() once (before
> > > > referencing $_SESSION), even if $_SESSION is accessed in an included
> > > > file.
> > > >
> > > > --
> > > > 
> > > > daniel.br...@parasane.net || danbr...@php.net
> > > > http://www.parasane.net/ || http://www.pilotpig.net/
> > > > Check out our hosting and dedicated server deals at
> > > > http://twitter.com/pilotpig
> > > >
> > > > --
> > > > PHP General Mailing List (http://www.php.net/)
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > Some people have a file called init.php, which would contain
> > > session_start(); as well as other things that need to be done every
> page
> > > load (connect to the database perhaps?) and they just 'require' that at
> > > the top of every page.
> > >
> > > --
> > > Luke Slater
> > > http://dinosaur-os.com/
> > >
> > > :O)
> >
> > Never thought of that. Sounds like quite a good idea.
> > Can anyone tell me if there's any reason for not doing that, even on
> pages
> > that do not require session data?
> > Or perhaps use an htaccess file to server side include a file file to all
> > files under an admin folder or something and another to destroy the
> > session. I'm thinking of smaller, low-traffic sites.
> > I know people are going to say, if they're small sites, why can't you
> only
> > start sessions on the relevant pages but it sounds like it could work
> well
> > for me.
>
>
> It's easier to maintain if you use one include file like Luke said. You
> won't
> get much overhead from a call to session_start() on a page that doesn't use
> sessions.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>

Great,
Cheers Ash,

T

-- 
Tom Chubb
t...@tomchubb.com | tomch...@gmail.com

Re: [PHP] Sessions

[Ashley Sheridan]

On Friday 03 July 2009 09:41:40 Tom Chubb wrote:
> 2009/7/3 Luke 
>
> > 2009/7/3 Daniel Brown 
> >
> > > On Thu, Jul 2, 2009 at 23:27, Jason Carson wrote:
> > > > Hello all,
> > > >
> > > > Do I have to add session_start() at the beginning of every page so
> > > > that the $_SESSION variables work on all pages or do I use
> > > > session_start()
> >
> > on
> >
> > > > the first page and something else on other pages?
> > >
> > > Yes, unless you're using session autoloading.  Also, in most
> > > cases, you will only need to call session_start() once (before
> > > referencing $_SESSION), even if $_SESSION is accessed in an included
> > > file.
> > >
> > > --
> > > 
> > > daniel.br...@parasane.net || danbr...@php.net
> > > http://www.parasane.net/ || http://www.pilotpig.net/
> > > Check out our hosting and dedicated server deals at
> > > http://twitter.com/pilotpig
> > >
> > > --
> > > PHP General Mailing List (http://www.php.net/)
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > Some people have a file called init.php, which would contain
> > session_start(); as well as other things that need to be done every page
> > load (connect to the database perhaps?) and they just 'require' that at
> > the top of every page.
> >
> > --
> > Luke Slater
> > http://dinosaur-os.com/
> >
> > :O)
>
> Never thought of that. Sounds like quite a good idea.
> Can anyone tell me if there's any reason for not doing that, even on pages
> that do not require session data?
> Or perhaps use an htaccess file to server side include a file file to all
> files under an admin folder or something and another to destroy the
> session. I'm thinking of smaller, low-traffic sites.
> I know people are going to say, if they're small sites, why can't you only
> start sessions on the relevant pages but it sounds like it could work well
> for me.


It's easier to maintain if you use one include file like Luke said. You won't 
get much overhead from a call to session_start() on a page that doesn't use 
sessions.

Thanks,
Ash
http://www.ashleysheridan.co.uk

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions

[Tom Chubb]

2009/7/3 Luke 

> 2009/7/3 Daniel Brown 
>
> > On Thu, Jul 2, 2009 at 23:27, Jason Carson wrote:
> > > Hello all,
> > >
> > > Do I have to add session_start() at the beginning of every page so that
> > > the $_SESSION variables work on all pages or do I use session_start()
> on
> > > the first page and something else on other pages?
> >
> > Yes, unless you're using session autoloading.  Also, in most
> > cases, you will only need to call session_start() once (before
> > referencing $_SESSION), even if $_SESSION is accessed in an included
> > file.
> >
> > --
> > 
> > daniel.br...@parasane.net || danbr...@php.net
> > http://www.parasane.net/ || http://www.pilotpig.net/
> > Check out our hosting and dedicated server deals at
> > http://twitter.com/pilotpig
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> Some people have a file called init.php, which would contain
> session_start(); as well as other things that need to be done every page
> load (connect to the database perhaps?) and they just 'require' that at the
> top of every page.
>
> --
> Luke Slater
> http://dinosaur-os.com/
> :O)
>

Never thought of that. Sounds like quite a good idea.
Can anyone tell me if there's any reason for not doing that, even on pages
that do not require session data?
Or perhaps use an htaccess file to server side include a file file to all
files under an admin folder or something and another to destroy the session.
I'm thinking of smaller, low-traffic sites.
I know people are going to say, if they're small sites, why can't you only
start sessions on the relevant pages but it sounds like it could work well
for me.

Re: [PHP] Sessions

[Luke]

2009/7/3 Daniel Brown 

> On Thu, Jul 2, 2009 at 23:27, Jason Carson wrote:
> > Hello all,
> >
> > Do I have to add session_start() at the beginning of every page so that
> > the $_SESSION variables work on all pages or do I use session_start() on
> > the first page and something else on other pages?
>
> Yes, unless you're using session autoloading.  Also, in most
> cases, you will only need to call session_start() once (before
> referencing $_SESSION), even if $_SESSION is accessed in an included
> file.
>
> --
> 
> daniel.br...@parasane.net || danbr...@php.net
> http://www.parasane.net/ || http://www.pilotpig.net/
> Check out our hosting and dedicated server deals at
> http://twitter.com/pilotpig
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Some people have a file called init.php, which would contain
session_start(); as well as other things that need to be done every page
load (connect to the database perhaps?) and they just 'require' that at the
top of every page.

-- 
Luke Slater
http://dinosaur-os.com/
:O)

Re: [PHP] Sessions

[Daniel Brown]

On Thu, Jul 2, 2009 at 23:27, Jason Carson wrote:
> Hello all,
>
> Do I have to add session_start() at the beginning of every page so that
> the $_SESSION variables work on all pages or do I use session_start() on
> the first page and something else on other pages?

Yes, unless you're using session autoloading.  Also, in most
cases, you will only need to call session_start() once (before
referencing $_SESSION), even if $_SESSION is accessed in an included
file.

-- 

daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our hosting and dedicated server deals at http://twitter.com/pilotpig

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions tutorial

[Bastien Koert]

[snip]
> Information on how to skin a cat.
> It's amazing how many ways there are too do it.
>
> I think it is in the neighborhood of 282,000.
[/snip]

Still tastes like chicken!



-- 

Bastien

Cat, the other other white meat

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions tutorial

[Michael A. Peters]

PJ wrote:

 I would
appreciate hearing of a tutorial that will give something more than "you
can use sessions in to store information"; like what kind of
information


Information on how to skin a cat.
It's amazing how many ways there are too do it.

I think it is in the neighborhood of 282,000.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] sessions tutorial

[Thodoris]

Top of the list is for real dummies at tizag.com.
So I don't have to search 282,000 entries for php sessions tutorial
(doesn't this say something about the stupidity on the internet - just
how many of those entries could possibly be real and worth looking at?
Since you "gurus" (I kowtow) have been there, done that, I would
appreciate hearing of a tutorial that will give something more than "you
can use sessions in to store information"; like what kind of
information, just how is it used e.g. whatis this, where did it come
from, what does it mean? -- if (isset($_REQUEST["ReturnToBooksList"]))
and  if (!isset($_SESSION["addNewBooks"])) - in these examples it come
from inputs. They were not specifically declared or is this a
declaration by itself... how can I find this information so I can
understand how to use it?
I really don't want to bother you guys but do you see the futility here?
My little programs are advancing little by little, but boy is it a
struggle to get any information. I eventually dig it out but, frankly,
it might be more productive digging salt mines in the Urals. :-(
PJ "the bitcher"

  


You could always read the manual for starters:

http://www.php.net/manual/en/book.session.php

It gives you a pretty good picture on sessions. Google could also help 
as usual:


http://www.google.gr/search?q=php+how+to+use+sessions&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:el:official&client=firefox-a

besides the first hit which is tizag there others you could look into 
for info.


I know I've stated the *obvious* but I think you should try it nonetheless.


--
Thodoris

RE: [PHP] sessions tutorial

[Arno Kuhl]

-Original Message-
From: PJ [mailto:af.gour...@videotron.ca] 
Sent: 18 June 2009 11:28 PM
To: php-general@lists.php.net
Subject: [PHP] sessions tutorial

Top of the list is for real dummies at tizag.com.
So I don't have to search 282,000 entries for php sessions tutorial (doesn't
this say something about the stupidity on the internet - just how many of
those entries could possibly be real and worth looking at?
Since you "gurus" (I kowtow) have been there, done that, I would appreciate
hearing of a tutorial that will give something more than "you can use
sessions in to store information"; like what kind of information, just how
is it used e.g. whatis this, where did it come from, what does it mean? --
if (isset($_REQUEST["ReturnToBooksList"]))
and  if (!isset($_SESSION["addNewBooks"])) - in these examples it come from
inputs. They were not specifically declared or is this a declaration by
itself... how can I find this information so I can understand how to use it?
I really don't want to bother you guys but do you see the futility here?
My little programs are advancing little by little, but boy is it a struggle
to get any information. I eventually dig it out but, frankly, it might be
more productive digging salt mines in the Urals. :-( PJ "the bitcher"

--
Hervé Kempf: "Pour sauver la planète, sortez du capitalisme."
-
Phil Jourdan --- p...@ptahhotep.com
   http://www.ptahhotep.com
   http://www.chiccantine.com/andypantry.php


-- 

"Pour sauver la planète, sortez du capitalisme." - pinko liberal ;)

I'm sure someone else has already proposed this, but... Get an entry-level
book on php, it will answer all your current and future questions about
arrays, forms, sessions, etc. Alternatively look at VTC or Lynda.com for
their excellent video tutorials. I'm sure many of the "gurus" you refer to
on this list started their path to gurudom by going through one or both
these routes. Definitely easier than digging salt mines, and has the added
advantage of enlightening you to new possibilities you hadn't thought of
before. I've done both (but I'm no guru) and I can definitely recommend
both, especially having a book around for a reference when you want to
quickly check something - easier than trying to find the reference in a
video.

Cheers
Arno


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions in object oriented code

[Diogo Neves]

Well, without code is dificult to say, but session_start() don't send
headers, then possible u have a space after a "?>" or @ least this is the
common error...

On Thu, Oct 30, 2008 at 11:47 PM, Ben Stones <[EMAIL PROTECTED]>wrote:

> Hi,
>
> Hope I can explain this as easily as possible, basically I am using both
> cookies and sessions for my script, whereby the user is allowed to choose
> which method they want to login with. Problem for me is removing the
> registration form, etc., from those that are logged in. The thing is the
> form is in its own method in a seperate file, and its called within HTML
> code so obviously if I included session_start() in the seperate include
> file
> where the methods/classes are, etc., I'd get a "headers already sent"
> error.
> So is there a solution to this?
>
> Thanks.
>

-- 
Thanks,

Diogo Neves
Web Developer @ SAPO.pt by PrimeIT.pt

Re: [PHP] Sessions in object oriented code

[Yeti]

> I can't really understand that. Not sure if you understand my problem
> properly (if I've not explained properly). Anyone can give me some solutions
> please?
Well as long as you don not provide any code it's all just wild guesses.
What I tried was to show you a way of simply preventing the HTML from
being sent to the browser before you include the session and/or cookie
file. So you would just have to add the output buffering syntax to
your existing code without changing all the scripts.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions in object oriented code

[Ashley Sheridan]

On Fri, 2008-10-31 at 00:33 +, Ben Stones wrote:
> Hi,
> 
> I can't really understand that. Not sure if you understand my problem
> properly (if I've not explained properly). Anyone can give me some solutions
> please?
> 
> Thanks.
> 
> 2008/10/31 Yeti <[EMAIL PROTECTED]>
> 
> > OK I guess it's somehow like this ..
> >
> > 
> >  > if (isset($_POST['submit'])) {
> > include('sessions.php');
> > // include sessions.php
> > }
> > ?>
> > 
> > 
> >
> > now this of course is something very bad to do and it wont work.
> > One way to prevent markup from being outputted is using ob_buffer() [1]
> >
> > EXAMPLE:
> >  > $form = << > 
> > 
> > 
> > FORM;
> > ob_start();
> > echo $form;
> > $output_buffer = ob_get_contents();
> > ob_end_clean();
> > var_dump(nl2br(htmlentities($output_buffer)));
> > ?>
> >
> > So what we do here is simply start the output buffer befor echoing $form.
> > ob_get_contents() returns the outputbuffer as it is right now.
> > By calling ob_end_clean() buffering is stopped and the buffer cache
> > released.
> > Still keep in mind that headers will still be sent when buffering the
> > output.
> >
> > here is a more complex
> > EXAMPLE:
> >  > ob_start(); // starting the output buffer
> > ?>
> > 
> >
> >
> >{{replace_me}}
> >
> > 
> >  > $output_buffer = ob_get_contents();
> > ob_end_clean();
> > session_start();
> > $_SESSION['test'] = time();
> > echo str_replace('{{replace_me}}', 'This is the replaced string. > />SESSION[test] was set to: '.$_SESSION['test'].'',
> > $output_buffer);
> > ?>
> >
> > Now we start the output buffer at the beginning of the script and the
> > session at the end.
> > It does not matter whether we close the PHP tag after starting the
> > ob_buffer. ( like with ?> )
> > As long as we do not flush_end or clean_end the output buffering
> > process it will continue caching the output (except headers).
> > So session_start should work after actually "outputting" markup.
> >
> > Another method could be like we did above the str_replace() [2] ...
> >
> > EXAMPLE:
> >  > $some_number = time();
> > $html = << > 
> >
> >Time: $some_number
> >{{replace_me}}
> >
> > 
> > HTML;
> > echo str_replace('{{replace_me}}', 'This string was changed by PHP',
> > $html);
> > ?>
> >
> > There is still plenty of other possible solutions. Keep on rocking
> >
> > [1] http://in.php.net/manual/en/ref.outcontrol.php
> > [2] http://in.php.net/manual/en/function.str-replace.php
> >
> > //A yeti
> >

How are you currently including the external file that has the
session_start() call? What I always do is have a basic config include
that contains only code that should have no output, like config
variables, database connections, and the session initiation. As sessions
rely (in general but not always) on cookies, then you should be calling
them both at once, as the only way to create a cookie after the headers
have been sent is with the use of javascript, which shouldn't be relied
on for something as fundamental as what you are trying to do.

As long as you have no output prior to the session_start() call (and
that means not even a single space) then you should be fine, no matter
whether the call is made from an include file or not.

If this still is no help, maybe you can give us a code excerpt so that
we can see what is the problem?


Ash
www.ashleysheridan.co.uk


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Sessions in object oriented code

[Ben Stones]

Hi,

I can't really understand that. Not sure if you understand my problem
properly (if I've not explained properly). Anyone can give me some solutions
please?

Thanks.

2008/10/31 Yeti <[EMAIL PROTECTED]>

> OK I guess it's somehow like this ..
>
> 
>  if (isset($_POST['submit'])) {
> include('sessions.php');
> // include sessions.php
> }
> ?>
> 
> 
>
> now this of course is something very bad to do and it wont work.
> One way to prevent markup from being outputted is using ob_buffer() [1]
>
> EXAMPLE:
>  $form = << 
> 
> 
> FORM;
> ob_start();
> echo $form;
> $output_buffer = ob_get_contents();
> ob_end_clean();
> var_dump(nl2br(htmlentities($output_buffer)));
> ?>
>
> So what we do here is simply start the output buffer befor echoing $form.
> ob_get_contents() returns the outputbuffer as it is right now.
> By calling ob_end_clean() buffering is stopped and the buffer cache
> released.
> Still keep in mind that headers will still be sent when buffering the
> output.
>
> here is a more complex
> EXAMPLE:
>  ob_start(); // starting the output buffer
> ?>
> 
>
>
>{{replace_me}}
>
> 
>  $output_buffer = ob_get_contents();
> ob_end_clean();
> session_start();
> $_SESSION['test'] = time();
> echo str_replace('{{replace_me}}', 'This is the replaced string. />SESSION[test] was set to: '.$_SESSION['test'].'',
> $output_buffer);
> ?>
>
> Now we start the output buffer at the beginning of the script and the
> session at the end.
> It does not matter whether we close the PHP tag after starting the
> ob_buffer. ( like with ?> )
> As long as we do not flush_end or clean_end the output buffering
> process it will continue caching the output (except headers).
> So session_start should work after actually "outputting" markup.
>
> Another method could be like we did above the str_replace() [2] ...
>
> EXAMPLE:
>  $some_number = time();
> $html = << 
>
>Time: $some_number
>{{replace_me}}
>
> 
> HTML;
> echo str_replace('{{replace_me}}', 'This string was changed by PHP',
> $html);
> ?>
>
> There is still plenty of other possible solutions. Keep on rocking
>
> [1] http://in.php.net/manual/en/ref.outcontrol.php
> [2] http://in.php.net/manual/en/function.str-replace.php
>
> //A yeti
>

Re: [PHP] Sessions in object oriented code

[Yeti]

OK I guess it's somehow like this ..






now this of course is something very bad to do and it wont work.
One way to prevent markup from being outputted is using ob_buffer() [1]

EXAMPLE:



FORM;
ob_start();
echo $form;
$output_buffer = ob_get_contents();
ob_end_clean();
var_dump(nl2br(htmlentities($output_buffer)));
?>

So what we do here is simply start the output buffer befor echoing $form.
ob_get_contents() returns the outputbuffer as it is right now.
By calling ob_end_clean() buffering is stopped and the buffer cache released.
Still keep in mind that headers will still be sent when buffering the output.

here is a more complex
EXAMPLE:




{{replace_me}}


This is the replaced string.SESSION[test] was set to: '.$_SESSION['test'].'',
$output_buffer);
?>

Now we start the output buffer at the beginning of the script and the
session at the end.
It does not matter whether we close the PHP tag after starting the
ob_buffer. ( like with ?> )
As long as we do not flush_end or clean_end the output buffering
process it will continue caching the output (except headers).
So session_start should work after actually "outputting" markup.

Another method could be like we did above the str_replace() [2] ...

EXAMPLE:


Time: $some_number
{{replace_me}}


HTML;
echo str_replace('{{replace_me}}', 'This string was changed by PHP', $html);
?>

There is still plenty of other possible solutions. Keep on rocking

[1] http://in.php.net/manual/en/ref.outcontrol.php
[2] http://in.php.net/manual/en/function.str-replace.php

//A yeti

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Philip Thompson]

On Sep 20, 2008, at 7:28 AM, Ashley Sheridan wrote:


On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote:

Hi all.

Let me start out by saying, I have STFW and read through the list
archives. Now that that's out of the way.

To speed up our application, we want to implement using SESSIONs in
some locations. Beforehand, on every page, we would run approximately
30-40 queries just to get the page setup - user information and other
stuff. Now while we can't take away all of the setup queries, we  
would

like to reduce the startup number.

Ok, so I've implemented this in several places where information
basically does not change from page to page. Jumping to the point/
question... when does it become more inefficient to store lots of
information in SESSION variables than to run several more queries?
Note, we are actually storing sessions in the database - so a read/
write is required on each page load - it's not file sessions.

Now I know this can depend on the complexity of the queries and how
much data is actually stored inside the sessions... but initial
thoughts? To give you a number, the strlen of the _SESSION array is
325463 - which is equivalent to the number of bytes (I think).

Thanks,
~Philip

Why do you have so many queries? Is there any way you could use  
joins to

drop that number down. It might not seem like  lot when only a few
people are using the site, but it will start being a problem when you
get more people using it.


Ash


Well, there are different queries depending on how *far* you get into  
the app. If you fail at level 2, why already grab the data that's need  
at level 5 or 6? And besides, using joins is expensive. The queries  
pull different data - if there's no relation between tables, a join  
won't work. However, because the database is normalized (to the 3rd  
degree), we use joins all over the place.


~Phil


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Per Jessen]

Lupus Michaelis wrote:

> Per Jessen a écrit :
> 
>> No, that wouldn't be the default behaviour.  /tmp is typically on the
>> filesystem, and it's not cleared on every reboot (unless your system
>> has been configured to do so).
> 
>In Debian based, it is the default behaviour. i hope it is the same
> in other major distributions. 

Well, it isn't.  SUSE and openSUSE have never cleared /tmp by default.  


/Per Jessen, Zürich


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Lupus Michaelis]

Per Jessen a écrit :


No, that wouldn't be the default behaviour.  /tmp is typically on the
filesystem, and it's not cleared on every reboot (unless your system
has been configured to do so). 


  In Debian based, it is the default behaviour. i hope it is the same 
in other major distributions. The last fashion is to use a tmpfs to 
mount /tmp


--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Per Jessen]

Philip Thompson wrote:

> Ok, so I've implemented this in several places where information
> basically does not change from page to page. Jumping to the point/
> question... when does it become more inefficient to store lots of
> information in SESSION variables than to run several more queries?
> Note, we are actually storing sessions in the database - so a read/
> write is required on each page load - it's not file sessions.

I don't think you're likely to see any measurable difference, not until
your sessions get VERY big (I'm guessing megabytes).  There's is
overhead associated with both forms - the SESSION data must be
serialized/de-serialized, the mysql calls organises data to/from an
associative array etc., but what is hauled out of the database is
essentially the same, it's only the transmission method that differs.


/Per Jessen, Zürich


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Per Jessen]

Eric Butera wrote:

> 
> Wouldn't you (probably) loose sessions in /tmp if the box crashed
> also?

No, that wouldn't be the default behaviour.  /tmp is typically on the
filesystem, and it's not cleared on every reboot (unless your system
has been configured to do so). 


/Per Jessen, Zürich


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Eric Butera]

On Sun, Sep 21, 2008 at 6:48 PM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> Philip Thompson schreef:
>>
>> Hi all.
>>
>> Let me start out by saying, I have STFW and read through the list
>> archives. Now that that's out of the way.
>>
>> To speed up our application, we want to implement using SESSIONs in some
>> locations. Beforehand, on every page, we would run approximately 30-40
>> queries just to get the page setup - user information and other stuff. Now
>> while we can't take away all of the setup queries, we would like to reduce
>> the startup number.
>>
>> Ok, so I've implemented this in several places where information basically
>> does not change from page to page. Jumping to the point/question... when
>> does it become more inefficient to store lots of information in SESSION
>> variables than to run several more queries? Note, we are actually storing
>> sessions in the database - so a read/write is required on each page load -
>> it's not file sessions.
>>
>> Now I know this can depend on the complexity of the queries and how much
>> data is actually stored inside the sessions... but initial thoughts? To give
>> you a number, the strlen of the _SESSION array is 325463 - which is
>> equivalent to the number of bytes (I think).
>
> not exactly - depends on how you measure it, also the serialized form of the
> session data is longer still because it contains data type descriptions et
> al.
>
> are you running on a linux box? if so try using session files again and
> sticking your session data in /dev/shm/some-dir which effectively means your
> sticking the files in RAM ... generally much faster than using a DB or the
> FS,
> on the other hand this is rather volatile (if the box goes down you lose all
> the
> data ... but then you have other problems probably, you can get round it
> by regularly backing up the contents of /dev/shm/some-dir and restoring the
> backup
> if/when the machine reboots ... the backup can occur out of process, so
> your page performance isn't directly effected, you'd still have to think
> about
> file locking etc) I use this trick quite often, generally without bothering
> to backup the session data (I figure if the site goes down completely then
> losing session data is the least of my worries ... and a user won't be
> all that surprised to find his login status wiped when the site comes back
> up ... although he/she might be a little miffed)
>
>>
>> Thanks,
>> ~Philip
>>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Wouldn't you (probably) loose sessions in /tmp if the box crashed also?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Jochem Maas]

Philip Thompson schreef:

Hi all.

Let me start out by saying, I have STFW and read through the list 
archives. Now that that's out of the way.


To speed up our application, we want to implement using SESSIONs in some 
locations. Beforehand, on every page, we would run approximately 30-40 
queries just to get the page setup - user information and other stuff. 
Now while we can't take away all of the setup queries, we would like to 
reduce the startup number.


Ok, so I've implemented this in several places where information 
basically does not change from page to page. Jumping to the 
point/question... when does it become more inefficient to store lots of 
information in SESSION variables than to run several more queries? Note, 
we are actually storing sessions in the database - so a read/write is 
required on each page load - it's not file sessions.


Now I know this can depend on the complexity of the queries and how much 
data is actually stored inside the sessions... but initial thoughts? To 
give you a number, the strlen of the _SESSION array is 325463 - which is 
equivalent to the number of bytes (I think).


not exactly - depends on how you measure it, also the serialized form of the
session data is longer still because it contains data type descriptions et al.

are you running on a linux box? if so try using session files again and
sticking your session data in /dev/shm/some-dir which effectively means your
sticking the files in RAM ... generally much faster than using a DB or the FS,
on the other hand this is rather volatile (if the box goes down you lose all the
data ... but then you have other problems probably, you can get round it
by regularly backing up the contents of /dev/shm/some-dir and restoring the 
backup
if/when the machine reboots ... the backup can occur out of process, so
your page performance isn't directly effected, you'd still have to think about
file locking etc) I use this trick quite often, generally without bothering
to backup the session data (I figure if the site goes down completely then
losing session data is the least of my worries ... and a user won't be
all that surprised to find his login status wiped when the site comes back
up ... although he/she might be a little miffed)



Thanks,
~Philip




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[tedd]

At 4:53 PM -0400 9/19/08, Jason Pruim wrote:

Time's off by an hour :)


That's probably a day-light saving thing -- doesn't matter anyway.


I could have my graphic designer whip something up hehee :)


The problem is not designing the form, but rather programming it. 
Each form takes a lot of time to get each element exactly where it 
should be.


But, anything a graphic designer can create, I can copy.

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[tedd]

At 9:31 PM +0100 9/19/08, Stut wrote:

On 19 Sep 2008, at 21:22, Robert Cummings wrote:

On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:

At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings 
<[EMAIL PROTECTED]> wrote:

   4. lack of industry adoption


There needs to be some sort of expensive test to certify one may wear
the badge.  Then it will have higher adoption rates.



I can modify this:

http://webbytedd.com/bb/pdf/


He said EXPENSIVE you insensitive clod!


Ahh, mood swings from ink poisoning?

Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!


I've thought about making a site where the user could enter in 
whatever degree they wanted (i.e, Harvard, Yale, whatever) and the 
site would print out the certificate for free. Then for $5.00, I 
would give them a one-time key to remove the "VOID" from the document.


How's that?

Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[tedd]

At 5:00 PM -0400 9/19/08, Robert Cummings wrote:

On Fri, 2008-09-19 at 21:31 +0100, Stut wrote:

 >>
 >> I can modify this:
 >>
 >> http://webbytedd.com/bb/pdf/
 >
 > He said EXPENSIVE you insensitive clod!

 Ahh, mood swings from ink poisoning?

 Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!

 I've managed to avoid getting the Zend certification until now despite 
 many many people trying to convince me it's worth it. As both an 
 employee and an employer I just don't see the value. The last practice 
 tests I saw were primarily memory tests - that's not a useful measure 
 in my book.


I'm also in the camp of avoiding getting Zend certification. As you
point out, it's merely a test on memorization of simple (and
occasionally obscure) language constructs. It's hardly an example of how
a person thinks, tackles problems, and can effectively develop
solutions.


I'm of the same notion. If my three degrees, on-line code examples, 
past work, willingness to show what I can do, and website aren't 
enough, then I'm not sure a Zend certification (or any certification 
for that matter) will help.


From my experience, I have more than enough to open any door, the 
problem is finding more doors.


I find it interesting that there are few programmers that can we and 
so many businesses have/want web sites, but I'm usually the one who's 
knocking on doors -- one would think it would be the other way around.


For the past year, I've worked with a company who provide me jobs. 
They find the clients and I do the work and that's worked out very 
well. But last month they told me that they are not happy with their 
business -- too many headaches dealing with clients and they will not 
be looking for more clients. So, I will be pounding the streets 
looking for work again.


I have clients looking for customers and I seem to be able to solve 
their problems, maybe I should hire myself? In any event, my website 
is going to receive a minor facelift and I'm trolling again.


Cheers,

tedd

--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Ashley Sheridan]

On Fri, 2008-09-19 at 10:17 -0500, Philip Thompson wrote:
> Hi all.
> 
> Let me start out by saying, I have STFW and read through the list  
> archives. Now that that's out of the way.
> 
> To speed up our application, we want to implement using SESSIONs in  
> some locations. Beforehand, on every page, we would run approximately  
> 30-40 queries just to get the page setup - user information and other  
> stuff. Now while we can't take away all of the setup queries, we would  
> like to reduce the startup number.
> 
> Ok, so I've implemented this in several places where information  
> basically does not change from page to page. Jumping to the point/ 
> question... when does it become more inefficient to store lots of  
> information in SESSION variables than to run several more queries?  
> Note, we are actually storing sessions in the database - so a read/ 
> write is required on each page load - it's not file sessions.
> 
> Now I know this can depend on the complexity of the queries and how  
> much data is actually stored inside the sessions... but initial  
> thoughts? To give you a number, the strlen of the _SESSION array is  
> 325463 - which is equivalent to the number of bytes (I think).
> 
> Thanks,
> ~Philip
> 
Why do you have so many queries? Is there any way you could use joins to
drop that number down. It might not seem like  lot when only a few
people are using the site, but it will start being a problem when you
get more people using it.


Ash
www.ashleysheridan.co.uk


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Stut]

On 19 Sep 2008, at 22:33, Philip Thompson wrote:

On Sep 19, 2008, at 4:01 PM, Stut wrote:

On 19 Sep 2008, at 21:44, Philip Thompson wrote:

On Sep 19, 2008, at 1:12 PM, Stut wrote:

On 19 Sep 2008, at 18:47, Philip Thompson wrote:

6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction


If all you're doing is issuing an update command there is no need  
to do so in a transaction and definitely no need to lock the row.  
An update is atomic.


Maybe what you actually mean to do here is lock it before you get  
the session data, make changes to it and then unlock it once  
you're done changing it. Doing that would likely keep the row  
locked for the entire duration of a request which can start  
causing problems as traffic increases.


I'm starting the transaction because MySQL "SELECT... FOR UPDATE"  
requires a transaction to lock the row. But now that I think about  
it... the reason we use the lock is so that we don't have  
collisions in data - specifically here the user session. However,  
the user session row is only accessed by a single user (his/her  
own). And since they can only be logged in at one location,  
there's virtually no way for a collision. Right? I can remove  
queries 6, 7, and 9, right?


Yes, you only need the update statement.


Ok, here, only the update is needed. But for other locations where  
multiple users may be accessing the same record, I should lock it.


Yes and no. If all you're going to do while it's locked is issue the  
update statement then it's pointless. However, if you need to prevent  
anyone from updating the row from when you read it to when you write  
it back then you need to lock it for the duration.


Note that these are the 10 queries that happen after the initial  
SESSION load. I supposed I could reduce this by 1 or 2 queries -  
I could store the page id/information in the session. Now with  
that said, the queries are negligible (in elapsed time) and  
required.


However, I'm always open up to suggestions/improvements =D


You may think they're required, but I'm betting they're not if  
you really think about it. However, if your DB can handle it then  
why fix something that ain't broken.


It can handle it now. But I'm not worried about now. We have less  
than 10 clients/offices using the app. This may grow up to 100  
within the next year. That's when there's gonna be lots and lots  
of data and we may start to see a slow down.


That's not even close to a large number of users, but it depends a  
lot on what else the servers you're hosting it on are being used for.


A client may have 1 user or 50 users. It's not the user-size I'm  
concerned about. This software is for doctor's offices. So, last  
week when we had our first import from another practice management  
system (aptly acronym'd, PMS), our patient records jumped from about  
1,000 to 65,000. That's just 1 client! Now, I still know that's not  
a whole lot, but multiply that by 100 clients in the next year:  
64000 * 100 = 6.4 million patient records. That's more of a  
significant number.


Not particularly, and to be honest the traffic to the site will be  
your problem, not the number of users or records stored on it. Queries  
can always be optimised but the architecture of the site is harder and  
more expensive to change.


We're using a dedicated server that hosts the website and the  
database. I *know* we're going to need to expand... but that's  
beyond my control as a mere pawn. As of today, it's okay.


Sounds like you've got an easy sharding option so you should be ok.  
Once you outgrow that single server it should be pretty simple to put  
a redirector on to a main server which will redirect after login to  
another server (shard) which contains all the data for that client.  
This is commonly the easiest sharding scenario to implement but it  
only works so long as a single client doesn't outgrow a single server.


-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Philip Thompson]

On Sep 19, 2008, at 4:01 PM, Stut wrote:


On 19 Sep 2008, at 21:44, Philip Thompson wrote:


On Sep 19, 2008, at 1:12 PM, Stut wrote:


On 19 Sep 2008, at 18:47, Philip Thompson wrote:

4. Grab user privs


IMHO you should only grab these when you need them.


I will need these on most pages anyway. Because of the  
architecture, the security class (which uses these a lot) is a  
separate part.


Fair enough, but I would suggest this is an ideal candidate for  
being kept in the session.


Yes, I agree - these can prob be moved into the session.


5. Grab user session (for application)


Again, why isn't this already in $_SESSION for every page request  
expect the first per visit?


This "user session" deals with merely keeping up with the time -  
how long has it been since this user accessed the site? Keep logged  
in? Logged in elsewhere? This uses the db and cookies. Note, this  
was designed into the app from the beginning... using the _SESSION  
var is new to the app as of this week. Yes, we can probably move  
this functionality into the new _SESSION stuff


Sounds like a lot of work for little benefit, but it sounds like it  
might be hard to remove so I'd probably live with it for a while too.


It may be some work... but it doesn't make sense to have session stuff  
in two different places. (I inherited this architecture, so I've been  
limited as to what I can do to some extent.) The question I have to  
ask myself now... will it be worth it in the future to have moved the  
session stuff to 1 class now? And do I have the time/resources to? =D



6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction


If all you're doing is issuing an update command there is no need  
to do so in a transaction and definitely no need to lock the row.  
An update is atomic.


Maybe what you actually mean to do here is lock it before you get  
the session data, make changes to it and then unlock it once  
you're done changing it. Doing that would likely keep the row  
locked for the entire duration of a request which can start  
causing problems as traffic increases.


I'm starting the transaction because MySQL "SELECT... FOR UPDATE"  
requires a transaction to lock the row. But now that I think about  
it... the reason we use the lock is so that we don't have  
collisions in data - specifically here the user session. However,  
the user session row is only accessed by a single user (his/her  
own). And since they can only be logged in at one location, there's  
virtually no way for a collision. Right? I can remove queries 6, 7,  
and 9, right?


Yes, you only need the update statement.


Ok, here, only the update is needed. But for other locations where  
multiple users may be accessing the same record, I should lock it.


Note that these are the 10 queries that happen after the initial  
SESSION load. I supposed I could reduce this by 1 or 2 queries -  
I could store the page id/information in the session. Now with  
that said, the queries are negligible (in elapsed time) and  
required.


However, I'm always open up to suggestions/improvements =D


You may think they're required, but I'm betting they're not if you  
really think about it. However, if your DB can handle it then why  
fix something that ain't broken.


It can handle it now. But I'm not worried about now. We have less  
than 10 clients/offices using the app. This may grow up to 100  
within the next year. That's when there's gonna be lots and lots of  
data and we may start to see a slow down.


That's not even close to a large number of users, but it depends a  
lot on what else the servers you're hosting it on are being used for.


A client may have 1 user or 50 users. It's not the user-size I'm  
concerned about. This software is for doctor's offices. So, last week  
when we had our first import from another practice management system  
(aptly acronym'd, PMS), our patient records jumped from about 1,000 to  
65,000. That's just 1 client! Now, I still know that's not a whole  
lot, but multiply that by 100 clients in the next year: 64000 * 100 =  
6.4 million patient records. That's more of a significant number.


We're using a dedicated server that hosts the website and the  
database. I *know* we're going to need to expand... but that's beyond  
my control as a mere pawn. As of today, it's okay.


The way I approach this stuff is always with the knowledge that  
the database is the most expensive resource in the infrastructure,  
so anything I can do to avoid using it when it's not strictly  
necessary is something I consider well-worth the effort.


With the rise of frameworks and the lazy architectures it's pretty  
common to end up with this mass of DB access at the start of each  
request, but it won't scale and it leads to assumptions that are  
extremely expensive to find and fix when you do need to scale.  
Trust me, I've been there many times and it's been painful every  
time!


Can y

Re: [PHP] SESSIONS vs. MySQL

[Stut]

On 19 Sep 2008, at 21:44, Philip Thompson wrote:


On Sep 19, 2008, at 1:12 PM, Stut wrote:


On 19 Sep 2008, at 18:47, Philip Thompson wrote:

4. Grab user privs


IMHO you should only grab these when you need them.


I will need these on most pages anyway. Because of the architecture,  
the security class (which uses these a lot) is a separate part.


Fair enough, but I would suggest this is an ideal candidate for being  
kept in the session.



5. Grab user session (for application)


Again, why isn't this already in $_SESSION for every page request  
expect the first per visit?


This "user session" deals with merely keeping up with the time - how  
long has it been since this user accessed the site? Keep logged in?  
Logged in elsewhere? This uses the db and cookies. Note, this was  
designed into the app from the beginning... using the _SESSION var  
is new to the app as of this week. Yes, we can probably move this  
functionality into the new _SESSION stuff


Sounds like a lot of work for little benefit, but it sounds like it  
might be hard to remove so I'd probably live with it for a while too.



6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction


If all you're doing is issuing an update command there is no need  
to do so in a transaction and definitely no need to lock the row.  
An update is atomic.


Maybe what you actually mean to do here is lock it before you get  
the session data, make changes to it and then unlock it once you're  
done changing it. Doing that would likely keep the row locked for  
the entire duration of a request which can start causing problems  
as traffic increases.


I'm starting the transaction because MySQL "SELECT... FOR UPDATE"  
requires a transaction to lock the row. But now that I think about  
it... the reason we use the lock is so that we don't have collisions  
in data - specifically here the user session. However, the user  
session row is only accessed by a single user (his/her own). And  
since they can only be logged in at one location, there's virtually  
no way for a collision. Right? I can remove queries 6, 7, and 9,  
right?


Yes, you only need the update statement.

Note that these are the 10 queries that happen after the initial  
SESSION load. I supposed I could reduce this by 1 or 2 queries - I  
could store the page id/information in the session. Now with that  
said, the queries are negligible (in elapsed time) and required.


However, I'm always open up to suggestions/improvements =D


You may think they're required, but I'm betting they're not if you  
really think about it. However, if your DB can handle it then why  
fix something that ain't broken.


It can handle it now. But I'm not worried about now. We have less  
than 10 clients/offices using the app. This may grow up to 100  
within the next year. That's when there's gonna be lots and lots of  
data and we may start to see a slow down.


That's not even close to a large number of users, but it depends a lot  
on what else the servers you're hosting it on are being used for.


The way I approach this stuff is always with the knowledge that the  
database is the most expensive resource in the infrastructure, so  
anything I can do to avoid using it when it's not strictly  
necessary is something I consider well-worth the effort.


With the rise of frameworks and the lazy architectures it's pretty  
common to end up with this mass of DB access at the start of each  
request, but it won't scale and it leads to assumptions that are  
extremely expensive to find and fix when you do need to scale.  
Trust me, I've been there many times and it's been painful every  
time!


Can you explain why it won't scale and may lead to assumptions?


Sure. With an architecture like this you start to assume that X is  
available anywhere in your code because at the moment you know the  
framework loads it for you. This makes it exceedingly difficult to  
strip the initialisation code down if you end up needing to optimise  
the crap out of it.


As far as scaling goes you're placing all the load on the database so  
if you get to a stage where you can no longer vertically scale the DB  
hardware you're left with a major rewrite of your entire codebase to  
allow it to scale horizontally. It's possible that your app is capable  
of being sharded across multiple servers but chances are that's still  
going to take major surgery to achieve.


Some on the list may have noticed I'm a bit anal about scalability  
issues, but it's only because I've inherited several systems now that  
were never designed with scalability in mind and I ended up almost  
completely rewriting each one. Every new site I develop now is built  
so it's modular, can spread across multiple servers if/when needed and  
doesn't waste resources. No doubt most web developers never hit these  
problems, but I guess I've just been unlucky in that respect.


-Stut

--
http://stut.net/

--
PHP 

Re: [PHP] SESSIONS vs. MySQL

[Robert Cummings]

On Fri, 2008-09-19 at 21:31 +0100, Stut wrote:
> >>
> >> I can modify this:
> >>
> >> http://webbytedd.com/bb/pdf/
> >
> > He said EXPENSIVE you insensitive clod!
> 
> Ahh, mood swings from ink poisoning?
> 
> Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!
> 
> I've managed to avoid getting the Zend certification until now despite  
> many many people trying to convince me it's worth it. As both an  
> employee and an employer I just don't see the value. The last practice  
> tests I saw were primarily memory tests - that's not a useful measure  
> in my book.

I'm also in the camp of avoiding getting Zend certification. As you
point out, it's merely a test on memorization of simple (and
occasionally obscure) language constructs. It's hardly an example of how
a person thinks, tackles problems, and can effectively develop
solutions.

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Jason Pruim]

Time's off by an hour :)

I could have my graphic designer whip something up hehee :)


On Sep 19, 2008, at 4:15 PM, tedd wrote:


At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED] 
> wrote:

   4. lack of industry adoption


There needs to be some sort of expensive test to certify one may wear
the badge.  Then it will have higher adoption rates.



I can modify this:

http://webbytedd.com/bb/pdf/

Cheers,

tedd



--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Philip Thompson]

I have more questions/responses throughout...

On Sep 19, 2008, at 1:12 PM, Stut wrote:


On 19 Sep 2008, at 18:47, Philip Thompson wrote:

I've narrowed it down to 10 initial queries...

1. Grab system config data (that's used in lots of places)


Does it change often? No? Then cache it in a PHP script. Use  
var_export to create a file that you can include which will create  
the configuration array. Alternatively cache it in a Memcache  
instance which is where my system-wide config usually lives.


Good idea.


2. Grab session data (for SESSION array)


Meaning what? You say below that this is after the initial session  
load. What are you loading here and why is it being loaded on every  
page request if it's ending up in the $_SESSION array?


Because I'm using your class, Stut, (at least as a reference) to store  
my sessions in the database. Hence, I have to pull them from the  
database.



3. Grab page id


What does this do, how is it used, is it needed?


I was able to add this to the SESSION.


4. Grab user privs


IMHO you should only grab these when you need them.


I will need these on most pages anyway. Because of the architecture,  
the security class (which uses these a lot) is a separate part.



5. Grab user session (for application)


Again, why isn't this already in $_SESSION for every page request  
expect the first per visit?


This "user session" deals with merely keeping up with the time - how  
long has it been since this user accessed the site? Keep logged in?  
Logged in elsewhere? This uses the db and cookies. Note, this was  
designed into the app from the beginning... using the _SESSION var is  
new to the app as of this week. Yes, we can probably move this  
functionality into the new _SESSION stuff



6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction


If all you're doing is issuing an update command there is no need to  
do so in a transaction and definitely no need to lock the row. An  
update is atomic.


Maybe what you actually mean to do here is lock it before you get  
the session data, make changes to it and then unlock it once you're  
done changing it. Doing that would likely keep the row locked for  
the entire duration of a request which can start causing problems as  
traffic increases.


I'm starting the transaction because MySQL "SELECT... FOR UPDATE"  
requires a transaction to lock the row. But now that I think about  
it... the reason we use the lock is so that we don't have collisions  
in data - specifically here the user session. However, the user  
session row is only accessed by a single user (his/her own). And since  
they can only be logged in at one location, there's virtually no way  
for a collision. Right? I can remove queries 6, 7, and 9, right?


10. Add page tracking (an insert-only table that keeps track of  
pages you visit)


I handle this using files and then have an offline processor to push  
that data into the database. If all you're doing is adding a row to  
the table you probably don't need this, but we do a fair amount of  
work for each page view to record the data in a set of tables  
designed for meaningful and speedy retrieval.


Note that these are the 10 queries that happen after the initial  
SESSION load. I supposed I could reduce this by 1 or 2 queries - I  
could store the page id/information in the session. Now with that  
said, the queries are negligible (in elapsed time) and required.


However, I'm always open up to suggestions/improvements =D


You may think they're required, but I'm betting they're not if you  
really think about it. However, if your DB can handle it then why  
fix something that ain't broken.


It can handle it now. But I'm not worried about now. We have less than  
10 clients/offices using the app. This may grow up to 100 within the  
next year. That's when there's gonna be lots and lots of data and we  
may start to see a slow down.


The way I approach this stuff is always with the knowledge that the  
database is the most expensive resource in the infrastructure, so  
anything I can do to avoid using it when it's not strictly necessary  
is something I consider well-worth the effort.


With the rise of frameworks and the lazy architectures it's pretty  
common to end up with this mass of DB access at the start of each  
request, but it won't scale and it leads to assumptions that are  
extremely expensive to find and fix when you do need to scale. Trust  
me, I've been there many times and it's been painful every time!


Can you explain why it won't scale and may lead to assumptions?

Oh, and by scale I don't necessarily mean to tens of millions of  
page views a month. Scalability is as much about going from 10  
visitor a day to 1000 as it is from 1000 to several million.


-Stut


Thanks,
~Philip


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Eric Butera]

On Fri, Sep 19, 2008 at 4:31 PM, Stut <[EMAIL PROTECTED]> wrote:
> On 19 Sep 2008, at 21:22, Robert Cummings wrote:
>>
>> On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
>>>
>>> At 3:11 PM -0400 9/19/08, Eric Butera wrote:

 On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED]>
 wrote:
>
>   4. lack of industry adoption

 There needs to be some sort of expensive test to certify one may wear
 the badge.  Then it will have higher adoption rates.
>>>
>>>
>>> I can modify this:
>>>
>>> http://webbytedd.com/bb/pdf/
>>
>> He said EXPENSIVE you insensitive clod!
>
> Ahh, mood swings from ink poisoning?
>
> Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!
>
> I've managed to avoid getting the Zend certification until now despite many
> many people trying to convince me it's worth it. As both an employee and an
> employer I just don't see the value. The last practice tests I saw were
> primarily memory tests - that's not a useful measure in my book.
>
> -Stut
>
> --
> http://stut.net/
>

Bingo.  :)

I can search php.net/ in 5 seconds to know the odd param order
of some string function if I forget.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Stut]

On 19 Sep 2008, at 21:22, Robert Cummings wrote:

On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:

At 3:11 PM -0400 9/19/08, Eric Butera wrote:
On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED] 
> wrote:

   4. lack of industry adoption


There needs to be some sort of expensive test to certify one may  
wear

the badge.  Then it will have higher adoption rates.



I can modify this:

http://webbytedd.com/bb/pdf/


He said EXPENSIVE you insensitive clod!


Ahh, mood swings from ink poisoning?

Tedd: Charge $100 per certificate, Rob'll buy one, maybe even two!!

I've managed to avoid getting the Zend certification until now despite  
many many people trying to convince me it's worth it. As both an  
employee and an employer I just don't see the value. The last practice  
tests I saw were primarily memory tests - that's not a useful measure  
in my book.


-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Robert Cummings]

On Fri, 2008-09-19 at 16:15 -0400, tedd wrote:
> At 3:11 PM -0400 9/19/08, Eric Butera wrote:
> >On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:
> >> 4. lack of industry adoption
> >
> >There needs to be some sort of expensive test to certify one may wear
> >the badge.  Then it will have higher adoption rates.
> 
> 
> I can modify this:
> 
> http://webbytedd.com/bb/pdf/

He said EXPENSIVE you insensitive clod!

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[tedd]

At 3:11 PM -0400 9/19/08, Eric Butera wrote:

On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:

4. lack of industry adoption


There needs to be some sort of expensive test to certify one may wear
the badge.  Then it will have higher adoption rates.



I can modify this:

http://webbytedd.com/bb/pdf/

Cheers,

tedd



--
---
http://sperling.com  http://ancientstones.com  http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Philip Thompson]

On Sep 19, 2008, at 1:12 PM, Stut wrote:


On 19 Sep 2008, at 18:47, Philip Thompson wrote:

I've narrowed it down to 10 initial queries...

1. Grab system config data (that's used in lots of places)


Does it change often? No? Then cache it in a PHP script. Use  
var_export to create a file that you can include which will create  
the configuration array. Alternatively cache it in a Memcache  
instance which is where my system-wide config usually lives.



2. Grab session data (for SESSION array)


Meaning what? You say below that this is after the initial session  
load. What are you loading here and why is it being loaded on every  
page request if it's ending up in the $_SESSION array?



3. Grab page id


What does this do, how is it used, is it needed?


4. Grab user privs


IMHO you should only grab these when you need them.


5. Grab user session (for application)


Again, why isn't this already in $_SESSION for every page request  
expect the first per visit?



6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction


If all you're doing is issuing an update command there is no need to  
do so in a transaction and definitely no need to lock the row. An  
update is atomic.


Maybe what you actually mean to do here is lock it before you get  
the session data, make changes to it and then unlock it once you're  
done changing it. Doing that would likely keep the row locked for  
the entire duration of a request which can start causing problems as  
traffic increases.


10. Add page tracking (an insert-only table that keeps track of  
pages you visit)


I handle this using files and then have an offline processor to push  
that data into the database. If all you're doing is adding a row to  
the table you probably don't need this, but we do a fair amount of  
work for each page view to record the data in a set of tables  
designed for meaningful and speedy retrieval.


Note that these are the 10 queries that happen after the initial  
SESSION load. I supposed I could reduce this by 1 or 2 queries - I  
could store the page id/information in the session. Now with that  
said, the queries are negligible (in elapsed time) and required.


However, I'm always open up to suggestions/improvements =D


You may think they're required, but I'm betting they're not if you  
really think about it. However, if your DB can handle it then why  
fix something that ain't broken.


The way I approach this stuff is always with the knowledge that the  
database is the most expensive resource in the infrastructure, so  
anything I can do to avoid using it when it's not strictly necessary  
is something I consider well-worth the effort.


With the rise of frameworks and the lazy architectures it's pretty  
common to end up with this mass of DB access at the start of each  
request, but it won't scale and it leads to assumptions that are  
extremely expensive to find and fix when you do need to scale. Trust  
me, I've been there many times and it's been painful every time!


Oh, and by scale I don't necessarily mean to tens of millions of  
page views a month. Scalability is as much about going from 10  
visitor a day to 1000 as it is from 1000 to several million.


-Stut


Robert/Stut,

Thanks for your words of wisdom. ;) I will take what you've said back  
to my team for us to discuss. That's why I like this list - allows me  
to view the problem(s) from a different angle, or two. ;)


~Philip


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Stut]

On 19 Sep 2008, at 19:50, Robert Cummings wrote:

On Fri, 2008-09-19 at 19:32 +0100, Stut wrote:

Anyways, where can I get a coder badge, they sound cool!! ;)


I just draw one with a pen on my chest to show interviewers. So far it
really hasn't worked out well but I've narrowed the problem down to  
the

following four possibilities:

   1. they don't like to see my pudgy body when I take my shirt off
  to show it off


I'll take your word for that!


   2. they're blinded by the light... my glowing white northern
  European complexion exacerbated by flourescent office lighting


Yeah, I'm gonna ignore that one too.


   3. they're not impressed enough with my ball point pen artwork


Possible. I've always found it difficult to draw on myself in the  
mirror.



   4. lack of industry adoption


This one sounds like a winner. In my experience employers don't assign  
any importance to non-standard qualifications, even if they are hand- 
drawn badges.



So far I'm leaning towards a combination of 1 and 2 ;)


Yeah, probably 1 more than 2.

This makes me wonder if there really are any idiots out there who've  
had the PHP logo tattooed  somewhere on their person. Scary thought.


-Stut

--
http://stut.net/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Eric Butera]

On Fri, Sep 19, 2008 at 2:50 PM, Robert Cummings <[EMAIL PROTECTED]> wrote:
>4. lack of industry adoption

There needs to be some sort of expensive test to certify one may wear
the badge.  Then it will have higher adoption rates.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Robert Cummings]

On Fri, 2008-09-19 at 19:32 +0100, Stut wrote:
> On 19 Sep 2008, at 19:20, Robert Cummings wrote:
> > On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:
> >>
> >> Oh, and by scale I don't necessarily mean to tens of millions of page
> >> views a month.
> >
> > Someone needs to take away your coder badge if you make a site that
> > can't handle 1000 views a day :)
> >
> > Not withstanding extreme edge cases doing unlikely processing for the
> > typical website :B
> 
> Have you seen some of the "advanced" websites kicked out by design  
> companies?
> 
> Also consider the sites that get stuck on shared servers with 1000's  
> of sites per machine using database servers with 1000's of DBs where  
> limiting your resource usage can become the difference between a  
> snappy site and one that nobody will use! And then try convincing your  
> local plumber that it's worth paying more than £2 a month for their  
> hosting!
> 
> Actually, scrap that. It's usually the design company that's  
> overloading their dedicated server, the plumber is then stuck paying  
> £25+ a month + content change charges when they don't know any better.
> 
> Anyways, where can I get a coder badge, they sound cool!! ;)

I just draw one with a pen on my chest to show interviewers. So far it
really hasn't worked out well but I've narrowed the problem down to the
following four possibilities:

1. they don't like to see my pudgy body when I take my shirt off
   to show it off

2. they're blinded by the light... my glowing white northern
   European complexion exacerbated by flourescent office lighting

3. they're not impressed enough with my ball point pen artwork

4. lack of industry adoption

So far I'm leaning towards a combination of 1 and 2 ;)

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Stut]

On 19 Sep 2008, at 19:20, Robert Cummings wrote:

On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:


Oh, and by scale I don't necessarily mean to tens of millions of page
views a month.


Someone needs to take away your coder badge if you make a site that
can't handle 1000 views a day :)

Not withstanding extreme edge cases doing unlikely processing for the
typical website :B


Have you seen some of the "advanced" websites kicked out by design  
companies?


Also consider the sites that get stuck on shared servers with 1000's  
of sites per machine using database servers with 1000's of DBs where  
limiting your resource usage can become the difference between a  
snappy site and one that nobody will use! And then try convincing your  
local plumber that it's worth paying more than £2 a month for their  
hosting!


Actually, scrap that. It's usually the design company that's  
overloading their dedicated server, the plumber is then stuck paying  
£25+ a month + content change charges when they don't know any better.


Anyways, where can I get a coder badge, they sound cool!! ;)

-Stut

--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] SESSIONS vs. MySQL

[Robert Cummings]

On Fri, 2008-09-19 at 19:12 +0100, Stut wrote:
>
> Oh, and by scale I don't necessarily mean to tens of millions of page
> views a month.

Someone needs to take away your coder badge if you make a site that
can't handle 1000 views a day :)

Not withstanding extreme edge cases doing unlikely processing for the
typical website :B

Cheers,
Rob.
-- 
http://www.interjinn.com
Application and Templating Framework for PHP


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php