Re: [PHP] Re: SESSION variables: How much is too much?
I prefer to reduce SESSION usage as much as possible. but I dont hesitate to use them if need arises. Points to note - Execution time: Only session_id is stored on the client's computer, and the actual data is stored on the server. so it will take nearly same time to process 100 session vars and 1 session var. - Security: While passing data trough hidden form fields, it is easy for the user to be change it. but its impossible (the user can change the session_id though) for the user to change the data stored in a session. - register_globals: i always set this off. but my host turned this on. had to spend 2 full days to find out what the problem was. coming back to you issue: IMHO storing stuff like MaxDisplayRecords, DefaultDisplayRecords, etc., in a SESSION var is the best solution. alternatives being - Hidden fields: this will add to unnecessary network traffic. - Use separate file: Why use a separate file if PHP does the job for you? - Use the database: If you have an existing connection this is OK. But this will become a bottle neck if u dont have an existing connection
[PHP] Re: SESSION variables: How much is too much?
At 7:30 PM -0400 7/8/09, D.M.Jackson wrote: Thanks guys. I was just wondering if it was common practice to pass all those variables in the SESSION object or if I was following a bad example because it was the first time that I had seen so many variables passed this way. If this is the typical way of handling this in php then I don't have a problem with it, I just wanted to make sure that I wasn't getting off to a bad start and picking up bad habits while learning php. Thanks, Mark Mark: As a personal choice, I try to reduce the number of variables I carry in sessions as much as possible. To me sessions are similar to Globals and Globals create an environment that is generally not conducive to writing self-contained and reusable code. Typically when I'm dealing with many variables, the variables are usually contained in a database. If this is the case, then I only pass the id of the record in a session and allow the page to open the database to retrieve the variables it needs. I have found that the more session variables you pass, the more complicated the code. 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] Re: SESSION variables: How much is too much?
Hi, OK, I did a count on the session.inc file and there appears to be 37 variables accessed through the $_SESSION object. By and large they all appear to be scalar variables that contain a counter or a path or a boolean. Nothing that looks like a big object. Mostly stuff like MaxDisplayRecords, DefaultDisplayRecords, Theme, DefaultTheme, CustomerId, RealName, CustomerBranch, Module, UserStockLocation, PageSize, AccessLevel, AttemptsCounter, Language, PageSecurityToken, DatabaseName...etc. Initially, when you hit the index page the session.inc file is included. From there, depending on what choices you make from the options displayed it assembles a page by calling the a php file that calls the database if needed, includes a header.inc file and a footer.inc file and builds the appropriate html for the body and of course, includes the session.inc file. My question is, assuming 37 variables of this type in the session.inc file, at what level of concurrent user access do you consider changing the way you do business here. Bare in mind that I don't comprehend a whole lot about server and database clustering and big enterprise big iron stuff like that. I'm just a guy trying to learn how to write decent php code that I don't have to be embarassed of when I shift gears in a new direction to add a marketable skill in my career development path. Thanks, Mark Paul M Foster pa...@quillandmouse.com wrote in message news:20090709010528.gx14...@quillandmouse.com... On Wed, Jul 08, 2009 at 06:55:24PM -0500, Shawn McKenzie wrote: D.M.Jackson wrote: Thanks guys. I was just wondering if it was common practice to pass all those variables in the SESSION object or if I was following a bad example because it was the first time that I had seen so many variables passed this way. If this is the typical way of handling this in php then I don't have a problem with it, I just wanted to make sure that I wasn't getting off to a bad start and picking up bad habits while learning php. Thanks, Mark Again, it depends upon whether you need those variables in the next page for example. Think of a wizard, where you fill some values in a form, click next, fill more values, click next, etc and then click finish. You may want to pass the values from each page to the next via the session and ultimately have them all available in the last page. There are others ways to do this, such as adding them as hidden inputs in the next pages, but I personally would use sessions. One other example might be user info, id, username, firstname, lastname, current access role etc. You may use these on every page, so once you retrieve them from the db, you can store them in the session. Any other info like email, age, register date whatever, you can retrieve only when needed. Just to provide a counterpoint to this, I would discourage using $_SESSION for more than absolutely necessary. If I have a situation such as Shawn mentions above, I pass values via hidden fields in the form. Most of the forms I create are backed by a database, so mostly I capture data from there. In addition, you can serialize data you wish to save and store it in a database or hidden field, and then unserialize it upon painting the next page. If I'm not mistaken, there's a limit to the data which can be stored in a session variable. I don't want to mistakenly hit that limit and wonder what happened. And besides, I just think $_SESSION should be reserved for *special* cases. And, as mentioned before, it's worthwhile asking yourself if you *really* need to remember a bunch of information from page to page. The need to do so may well be a result of lazy programming habits. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SESSION variables: How much is too much?
D.M.Jackson wrote: Hi, I'm trying to learn php mostly by reading the docs and pulling through other peoples projects for reference examples. One particular application I'm looking at has a ton of variables being handled through the SESSION global variable, probably about 25 or so variables. That just seems like alot. Since I'm pretty new to php I was wondering if this was typical and acceptable or if there was another best practice for maintaining large amounts of information throughout a session, like maybe persisting a temporary object in the database and passing a connection...or something. Or is just passing around a pile of variables directly in the SESSION object better? Thanks, Mark There is no difference between using session vars and storing vars in a file/db and retrieving them every page load yourself. It's really the same thing except sessions are more automagic. The main differences are that you of course reduce some overhead if you only need certain vars on certain pages or if you need them infrequently then you can store/retrieve them yourself. As far as a large amount of large objects, if you don't need them every page load then you may want to look at stuffing them in a db and only retrieving then when needed. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SESSION variables: How much is too much?
Shawn McKenzie wrote: D.M.Jackson wrote: Hi, I'm trying to learn php mostly by reading the docs and pulling through other peoples projects for reference examples. One particular application I'm looking at has a ton of variables being handled through the SESSION global variable, probably about 25 or so variables. That just seems like alot. Since I'm pretty new to php I was wondering if this was typical and acceptable or if there was another best practice for maintaining large amounts of information throughout a session, like maybe persisting a temporary object in the database and passing a connection...or something. Or is just passing around a pile of variables directly in the SESSION object better? Thanks, Mark There is no difference between using session vars and storing vars in a file/db and retrieving them every page load yourself. It's really the same thing except sessions are more automagic. The main differences are that you of course reduce some overhead if you only need certain vars on certain pages or if you need them infrequently then you can store/retrieve them yourself. As far as a large amount of large objects, if you don't need them every page load then you may want to look at stuffing them in a db and only retrieving then when needed. Shawn's right, just start using them. I was reluctant when I first started using PHP just because they seemed so special. Now, I use them for just about every page in an application. In fact, I'd like to session constants. Al. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SESSION variables: How much is too much?
Thanks guys. I was just wondering if it was common practice to pass all those variables in the SESSION object or if I was following a bad example because it was the first time that I had seen so many variables passed this way. If this is the typical way of handling this in php then I don't have a problem with it, I just wanted to make sure that I wasn't getting off to a bad start and picking up bad habits while learning php. Thanks, Mark D.M.Jackson cnoe...@catt.com wrote in message news:90.23.10517.08e14...@pb1.pair.com... Hi, I'm trying to learn php mostly by reading the docs and pulling through other peoples projects for reference examples. One particular application I'm looking at has a ton of variables being handled through the SESSION global variable, probably about 25 or so variables. That just seems like alot. Since I'm pretty new to php I was wondering if this was typical and acceptable or if there was another best practice for maintaining large amounts of information throughout a session, like maybe persisting a temporary object in the database and passing a connection...or something. Or is just passing around a pile of variables directly in the SESSION object better? Thanks, Mark -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: SESSION variables: How much is too much?
D.M.Jackson wrote: Thanks guys. I was just wondering if it was common practice to pass all those variables in the SESSION object or if I was following a bad example because it was the first time that I had seen so many variables passed this way. If this is the typical way of handling this in php then I don't have a problem with it, I just wanted to make sure that I wasn't getting off to a bad start and picking up bad habits while learning php. Thanks, Mark Again, it depends upon whether you need those variables in the next page for example. Think of a wizard, where you fill some values in a form, click next, fill more values, click next, etc and then click finish. You may want to pass the values from each page to the next via the session and ultimately have them all available in the last page. There are others ways to do this, such as adding them as hidden inputs in the next pages, but I personally would use sessions. One other example might be user info, id, username, firstname, lastname, current access role etc. You may use these on every page, so once you retrieve them from the db, you can store them in the session. Any other info like email, age, register date whatever, you can retrieve only when needed. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: SESSION variables: How much is too much?
On Wed, Jul 08, 2009 at 06:55:24PM -0500, Shawn McKenzie wrote: D.M.Jackson wrote: Thanks guys. I was just wondering if it was common practice to pass all those variables in the SESSION object or if I was following a bad example because it was the first time that I had seen so many variables passed this way. If this is the typical way of handling this in php then I don't have a problem with it, I just wanted to make sure that I wasn't getting off to a bad start and picking up bad habits while learning php. Thanks, Mark Again, it depends upon whether you need those variables in the next page for example. Think of a wizard, where you fill some values in a form, click next, fill more values, click next, etc and then click finish. You may want to pass the values from each page to the next via the session and ultimately have them all available in the last page. There are others ways to do this, such as adding them as hidden inputs in the next pages, but I personally would use sessions. One other example might be user info, id, username, firstname, lastname, current access role etc. You may use these on every page, so once you retrieve them from the db, you can store them in the session. Any other info like email, age, register date whatever, you can retrieve only when needed. Just to provide a counterpoint to this, I would discourage using $_SESSION for more than absolutely necessary. If I have a situation such as Shawn mentions above, I pass values via hidden fields in the form. Most of the forms I create are backed by a database, so mostly I capture data from there. In addition, you can serialize data you wish to save and store it in a database or hidden field, and then unserialize it upon painting the next page. If I'm not mistaken, there's a limit to the data which can be stored in a session variable. I don't want to mistakenly hit that limit and wonder what happened. And besides, I just think $_SESSION should be reserved for *special* cases. And, as mentioned before, it's worthwhile asking yourself if you *really* need to remember a bunch of information from page to page. The need to do so may well be a result of lazy programming habits. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables
Paul M Foster wrote: I'm not too clear on HTTP headers, cookies, and such. So here are questions related to that. Let's say I generate a random number that I want the user to enter in a form. When I generate the number, I store it in a session variable ($_SESSION). When the user submits the form, I check the number they enter with what I've stored in the session variable. Since this session variable survives across page loads (assuming session_start() is appropriately called), how is it stored and recalled? Is it automatically stored as a cookie on the user's system? Or is it stored on the server? And how does a server get a cookie? Is it a separate request made by the server to the client? If the value I've asked the user for is *not* stored as a cookie, then is it passed as part of the HTTP submission or what? Thanks for any enlightenment on this. Paul seeing as you're a voomer here's a very mini explanation session has an id a: session id is passed to a user in the http headers users client gets sessionid and stores it in a cookie users client sends cookie with sessionid in it back to website every page load b: on the server a small file is stored in a temp directory containing all the stuff you've stored in session the file is named with the session id when php recieves a request, with a cookie, with a session id in it, then it grabs the related server side session files, pulls the variables from it an makes them available to you in $_SESSION. v simple :p -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
You're absolutely right, but the problem is not about how the SID is passed between the scripts, it is more about why some variables are written in the session file while others are not, even when these variables are created within the same script at the same time. If the SID was not correctly passed, it wouldn't find any other variables. I also wonder why this randomly happens ... I agree about the HTML/1.1 specs, I'm just a bit lazy ;) K. Shawn McKenzie a écrit : http://us.php.net/manual/en/function.header.php Note: Session ID is not passed with Location header even if session.use_trans_sid is enabled. It must by passed manually using SID constant. -Shawn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
Hi,
Ted Fabrice, thanks for your answers.
Sessions variables are only stored in a local file. The dir permissions are ok, and I've tried to store these files in another
dir (/var/tmp/php) just to check.
The session id is transmitted via cookies only :
session.use_cookies = 1
session.use_only_cookies = 1== I've tried with 0 and 1
session.auto_start = 0
session.cookie_lifetime = 0
I guess the Session ID is correctly transmitted because the errors doesn't occur on the first 2 scripts. First, the login page
requires cookies to be enabled, and this step is ok. Then the user has to choose something in a menu, this step is fine too :
some variables are set according to the user choice and the user is redirected to the 3rd script. The errors occur on this one.
Between the 2nd and 3rd scripts, variables are created from a database query : it _can't_ fail and the results are cheched : no
possible mistake here. I use this kind of method :
- the user chooses some $id (type and value tested, ok), then :
$res=pg_query($dbr, select a, b, c, ..., from table where table_id='$id');
if(pg_num_rows($res))
{
list($_SESSION[a], $_SESSION[b], $_SESSION[c], ...)=pg_fetch_row($res,
0);
pg_free_result($res);
header(Location:my_third_script.php);
exit();
}
Then the errors sometimes occur in my apache2/ssl_error_log (undefined index in $_SESSION variable). When I check the
sess_12345789... file, some of the variables are missing : $_SESSION[a] and [b] are there, but not $_SESSION[c], even an
empty one, it is just gone. That's all I know.
I would like to try to store my sessions variables in the main database, but it is quite difficult since the application is
currently used by many people. I'll also have to upgrade a lot of scripts (a bit time consuming) to test this solution...
Regards,
C.
Fabrice VIGNALS a écrit :
Difficult to help you because there are many method of session :
- where do you store the sessions_variables : in local file, db or cookie ?
- how you transmit the session id, beetween pages(runtimes) : cookie,
$GET link, database ?
Did you check the availability of user cookie if you use it ?
Because if in each page of your application you define a session
variable it's sure it will be every time here.
But the problem of session it's to transmit its ID between different
pages, or session will be reset.
If a user don't authorised cookie you must transmit the session id by db
storage or $Get link.
Also I don't see, a php modification during the last upgrades to explain
that's kind of session problem.
karma [EMAIL PROTECTED] a écrit dans le message de
news:[EMAIL PROTECTED]
Hi !
I have a very weird issue since the last Apache upgrade (- 2.2.8-r3,
a month ago), but I'm not sure it is related (well, I'm pretty sure
it's not).
Like many people, I've written an application that use PHP session
variables, like $_SESSION[my_variable].
Sometimes (it doesn't happen all the time), _some_ of these variables
are not written in the session file and they are lost after a simple
header(Location:...); (same domain). The session file is in the right
directory (permissions are fine), but some of my variables are missing.
The facts :
- Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date)
- all my scripts begin with session_start(). I've tried to add
session_write_close() before every header(Location:...) call, it
doesn't help.
- I didn't change anything in my program (it has been running just
fine for 2 years), it just began to fail from time to time (I would
say 10 times a day). There is no hidden unset() function : it would
fail for everyone.
- these variables are all set correctly, and they don't have reserved
names.
- only a few variables disappear, but they are always the same ones
(could it depend on their position in the session file ?!?)
- the session files are very small (max 100ko)
- it seems that it doesn't depend on the browser, but IE6 and IE7 seem
to be the most affected ones (it may be because my users mostly use
these browsers).
- I can't reproduce this issue from my local network (any OS/browser -
it would be too easy :)
- reverting to the previous stable Apache and/or PHP versions doesn't
help.
- I didn't change any php.ini directive.
Any idea ?
Thanks !
PS: if you need more details, just ask. The only thing I can't do is
pasting the code : the scripts are quite huge.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables disappear (some of them only)
Then the errors sometimes occur in my apache2/ssl_error_log (undefined index in $_SESSION variable). When I check the sess_12345789... file, some of the variables are missing : $_SESSION[a] and [b] are there, but not $_SESSION[c], even an empty one, it is just gone. That's all I know. Sounds like for those situations, the user doesn't have one of the options set (the database is returning a null value). Check that by matching up whatever 'a' and 'b' are with what's in the database. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
karma wrote:
Hi,
Ted Fabrice, thanks for your answers.
Sessions variables are only stored in a local file. The dir permissions
are ok, and I've tried to store these files in another dir
(/var/tmp/php) just to check.
The session id is transmitted via cookies only :
session.use_cookies = 1
session.use_only_cookies = 1== I've tried with 0 and 1
session.auto_start = 0
session.cookie_lifetime = 0
I guess the Session ID is correctly transmitted because the errors
doesn't occur on the first 2 scripts. First, the login page requires
cookies to be enabled, and this step is ok. Then the user has to choose
something in a menu, this step is fine too : some variables are set
according to the user choice and the user is redirected to the 3rd
script. The errors occur on this one.
Between the 2nd and 3rd scripts, variables are created from a database
query : it _can't_ fail and the results are cheched : no possible
mistake here. I use this kind of method :
- the user chooses some $id (type and value tested, ok), then :
$res=pg_query($dbr, select a, b, c, ..., from table where
table_id='$id');
if(pg_num_rows($res))
{
list($_SESSION[a], $_SESSION[b], $_SESSION[c],
...)=pg_fetch_row($res, 0);
pg_free_result($res);
header(Location:my_third_script.php);
exit();
}
Then the errors sometimes occur in my apache2/ssl_error_log (undefined
index in $_SESSION variable). When I check the sess_12345789... file,
some of the variables are missing : $_SESSION[a] and [b] are there,
but not $_SESSION[c], even an empty one, it is just gone. That's all I
know.
I would like to try to store my sessions variables in the main database,
but it is quite difficult since the application is currently used by
many people. I'll also have to upgrade a lot of scripts (a bit time
consuming) to test this solution...
Regards,
C.
Fabrice VIGNALS a écrit :
Difficult to help you because there are many method of session :
- where do you store the sessions_variables : in local file, db or
cookie ?
- how you transmit the session id, beetween pages(runtimes) : cookie,
$GET link, database ?
Did you check the availability of user cookie if you use it ?
Because if in each page of your application you define a session
variable it's sure it will be every time here.
But the problem of session it's to transmit its ID between different
pages, or session will be reset.
If a user don't authorised cookie you must transmit the session id by
db storage or $Get link.
Also I don't see, a php modification during the last upgrades to
explain that's kind of session problem.
karma [EMAIL PROTECTED] a écrit dans le message de
news:[EMAIL PROTECTED]
Hi !
I have a very weird issue since the last Apache upgrade (- 2.2.8-r3,
a month ago), but I'm not sure it is related (well, I'm pretty sure
it's not).
Like many people, I've written an application that use PHP session
variables, like $_SESSION[my_variable].
Sometimes (it doesn't happen all the time), _some_ of these variables
are not written in the session file and they are lost after a simple
header(Location:...); (same domain). The session file is in the
right directory (permissions are fine), but some of my variables are
missing.
The facts :
- Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date)
- all my scripts begin with session_start(). I've tried to add
session_write_close() before every header(Location:...) call, it
doesn't help.
- I didn't change anything in my program (it has been running just
fine for 2 years), it just began to fail from time to time (I would
say 10 times a day). There is no hidden unset() function : it would
fail for everyone.
- these variables are all set correctly, and they don't have reserved
names.
- only a few variables disappear, but they are always the same ones
(could it depend on their position in the session file ?!?)
- the session files are very small (max 100ko)
- it seems that it doesn't depend on the browser, but IE6 and IE7
seem to be the most affected ones (it may be because my users mostly
use these browsers).
- I can't reproduce this issue from my local network (any OS/browser
- it would be too easy :)
- reverting to the previous stable Apache and/or PHP versions doesn't
help.
- I didn't change any php.ini directive.
Any idea ?
Thanks !
PS: if you need more details, just ask. The only thing I can't do is
pasting the code : the scripts are quite huge.
http://us.php.net/manual/en/function.header.php
Note: Session ID is not passed with Location header even if
session.use_trans_sid is enabled. It must by passed manually using SID
constant.
-Shawn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
karma wrote:
Hi,
Ted Fabrice, thanks for your answers.
Sessions variables are only stored in a local file. The dir permissions
are ok, and I've tried to store these files in another dir
(/var/tmp/php) just to check.
The session id is transmitted via cookies only :
session.use_cookies = 1
session.use_only_cookies = 1== I've tried with 0 and 1
session.auto_start = 0
session.cookie_lifetime = 0
I guess the Session ID is correctly transmitted because the errors
doesn't occur on the first 2 scripts. First, the login page requires
cookies to be enabled, and this step is ok. Then the user has to choose
something in a menu, this step is fine too : some variables are set
according to the user choice and the user is redirected to the 3rd
script. The errors occur on this one.
Between the 2nd and 3rd scripts, variables are created from a database
query : it _can't_ fail and the results are cheched : no possible
mistake here. I use this kind of method :
- the user chooses some $id (type and value tested, ok), then :
$res=pg_query($dbr, select a, b, c, ..., from table where
table_id='$id');
if(pg_num_rows($res))
{
list($_SESSION[a], $_SESSION[b], $_SESSION[c],
...)=pg_fetch_row($res, 0);
pg_free_result($res);
header(Location:my_third_script.php);
exit();
}
Then the errors sometimes occur in my apache2/ssl_error_log (undefined
index in $_SESSION variable). When I check the sess_12345789... file,
some of the variables are missing : $_SESSION[a] and [b] are there,
but not $_SESSION[c], even an empty one, it is just gone. That's all I
know.
I would like to try to store my sessions variables in the main database,
but it is quite difficult since the application is currently used by
many people. I'll also have to upgrade a lot of scripts (a bit time
consuming) to test this solution...
Regards,
C.
Fabrice VIGNALS a écrit :
Difficult to help you because there are many method of session :
- where do you store the sessions_variables : in local file, db or
cookie ?
- how you transmit the session id, beetween pages(runtimes) : cookie,
$GET link, database ?
Did you check the availability of user cookie if you use it ?
Because if in each page of your application you define a session
variable it's sure it will be every time here.
But the problem of session it's to transmit its ID between different
pages, or session will be reset.
If a user don't authorised cookie you must transmit the session id by
db storage or $Get link.
Also I don't see, a php modification during the last upgrades to
explain that's kind of session problem.
karma [EMAIL PROTECTED] a écrit dans le message de
news:[EMAIL PROTECTED]
Hi !
I have a very weird issue since the last Apache upgrade (- 2.2.8-r3,
a month ago), but I'm not sure it is related (well, I'm pretty sure
it's not).
Like many people, I've written an application that use PHP session
variables, like $_SESSION[my_variable].
Sometimes (it doesn't happen all the time), _some_ of these variables
are not written in the session file and they are lost after a simple
header(Location:...); (same domain). The session file is in the
right directory (permissions are fine), but some of my variables are
missing.
The facts :
- Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date)
- all my scripts begin with session_start(). I've tried to add
session_write_close() before every header(Location:...) call, it
doesn't help.
- I didn't change anything in my program (it has been running just
fine for 2 years), it just began to fail from time to time (I would
say 10 times a day). There is no hidden unset() function : it would
fail for everyone.
- these variables are all set correctly, and they don't have reserved
names.
- only a few variables disappear, but they are always the same ones
(could it depend on their position in the session file ?!?)
- the session files are very small (max 100ko)
- it seems that it doesn't depend on the browser, but IE6 and IE7
seem to be the most affected ones (it may be because my users mostly
use these browsers).
- I can't reproduce this issue from my local network (any OS/browser
- it would be too easy :)
- reverting to the previous stable Apache and/or PHP versions doesn't
help.
- I didn't change any php.ini directive.
Any idea ?
Thanks !
PS: if you need more details, just ask. The only thing I can't do is
pasting the code : the scripts are quite huge.
Also:
Note: HTTP/1.1 requires an absolute URI as argument to » Location:
including the scheme, hostname and absolute path.
-Shawn
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
Difficult to help you because there are many method of session : - where do you store the sessions_variables : in local file, db or cookie ? - how you transmit the session id, beetween pages(runtimes) : cookie, $GET link, database ? Did you check the availability of user cookie if you use it ? Because if in each page of your application you define a session variable it's sure it will be every time here. But the problem of session it's to transmit its ID between different pages, or session will be reset. If a user don't authorised cookie you must transmit the session id by db storage or $Get link. Also I don't see, a php modification during the last upgrades to explain that's kind of session problem. karma [EMAIL PROTECTED] a écrit dans le message de news:[EMAIL PROTECTED] Hi ! I have a very weird issue since the last Apache upgrade (- 2.2.8-r3, a month ago), but I'm not sure it is related (well, I'm pretty sure it's not). Like many people, I've written an application that use PHP session variables, like $_SESSION[my_variable]. Sometimes (it doesn't happen all the time), _some_ of these variables are not written in the session file and they are lost after a simple header(Location:...); (same domain). The session file is in the right directory (permissions are fine), but some of my variables are missing. The facts : - Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date) - all my scripts begin with session_start(). I've tried to add session_write_close() before every header(Location:...) call, it doesn't help. - I didn't change anything in my program (it has been running just fine for 2 years), it just began to fail from time to time (I would say 10 times a day). There is no hidden unset() function : it would fail for everyone. - these variables are all set correctly, and they don't have reserved names. - only a few variables disappear, but they are always the same ones (could it depend on their position in the session file ?!?) - the session files are very small (max 100ko) - it seems that it doesn't depend on the browser, but IE6 and IE7 seem to be the most affected ones (it may be because my users mostly use these browsers). - I can't reproduce this issue from my local network (any OS/browser - it would be too easy :) - reverting to the previous stable Apache and/or PHP versions doesn't help. - I didn't change any php.ini directive. Any idea ? Thanks ! PS: if you need more details, just ask. The only thing I can't do is pasting the code : the scripts are quite huge. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables disappear (some of them only)
At 1:48 PM +0200 7/6/08, Fabrice VIGNALS wrote: Difficult to help you because there are many method of session : - where do you store the sessions_variables : in local file, db or cookie ? - how you transmit the session id, beetween pages(runtimes) : cookie, $GET link, database ? Did you check the availability of user cookie if you use it ? Because if in each page of your application you define a session variable it's sure it will be every time here. But the problem of session it's to transmit its ID between different pages, or session will be reset. If a user don't authorised cookie you must transmit the session id by db storage or $Get link. Also I don't see, a php modification during the last upgrades to explain that's kind of session problem. karma [EMAIL PROTECTED] a écrit dans le message de news:[EMAIL PROTECTED] Hi ! I have a very weird issue since the last Apache upgrade (- 2.2.8-r3, a month ago), but I'm not sure it is related (well, I'm pretty sure it's not). Like many people, I've written an application that use PHP session variables, like $_SESSION[my_variable]. Sometimes (it doesn't happen all the time), _some_ of these variables are not written in the session file and they are lost after a simple header(Location:...); (same domain). The session file is in the right directory (permissions are fine), but some of my variables are missing. The facts : - Apache 2.2.9 + PHP 5.2.6_rc4 running on a Gentoo (up-to-date) - all my scripts begin with session_start(). I've tried to add session_write_close() before every header(Location:...) call, it doesn't help. - I didn't change anything in my program (it has been running just fine for 2 years), it just began to fail from time to time (I would say 10 times a day). There is no hidden unset() function : it would fail for everyone. - these variables are all set correctly, and they don't have reserved names. - only a few variables disappear, but they are always the same ones (could it depend on their position in the session file ?!?) - the session files are very small (max 100ko) - it seems that it doesn't depend on the browser, but IE6 and IE7 seem to be the most affected ones (it may be because my users mostly use these browsers). - I can't reproduce this issue from my local network (any OS/browser - it would be too easy :) - reverting to the previous stable Apache and/or PHP versions doesn't help. - I didn't change any php.ini directive. Any idea ? Thanks ! If it's any comfort, I had a similar problem sending session variables from a script in a httpdocs directory to a script in a httpsdocs. Some of the variables made it and some didn't. It was very confusing. The client had php 4.3.1 installed, if that's any help. I never did find out what the problem was and I finally passed everything via a POST. 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] Re: Session variables on Windows
Well Do you have folder called tmp in your root? ThePanister! Tom [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Does some well-known problem exist with the session variables in Windows servers? Because in a system that I have running on a Windows server, sometimes the session variables are null causing errors, then I close the browser and open it and in the next intent everything works well... I can't understand why... The same system in a Linux server runs well always ¿? Ahead of time, thank you very much, Tom. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Jason Barnett wrote:
Adam wrote:
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
Well ok, but why can't you just have saveToSession() in the conditional
block?
?php
$_SESSION['Request'] = Request::getInstance();
look $_SESSION['Request'] is now a reference to the Request getInstance();
when this session is closed the object will automatically be serialized - no
need
to saveToSession or whatever! just make sure you have always declared the
Request class
before you start the session.
so have the Request::getInstance() deal with checking/setting
$_SESSION['Request'] internally.
if ($_SESSION['Request']-isRefresh() ) {
$_SESSION['Request']-saveToSession();
/* etc. */
exit();
}
/* Rest of script follows here */
?
IMHO the point of OOP is to keep each function split into the minimal
functionality that you need. This allows you to reuse code easier
because a function does only the *minimum* amount of work necessary
instead of extra (unintended) functionality.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
2) must provide mechanism for generating per session uniqe request
identiers. now implemented as md5($_SESSION[next_reqest_id]++) not very
effective but handy:-P
3) must be serializable (this is why i can not put that session manipulation
at __sleep function)
these requirements (1,3) cast out __destruct, __sleep and explicit call to
some saveToSession function. do You have any other idea when to store this
information , please?
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
*doh* i don't know how could i coverlooke taht user reaction:-( thank You.
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
Isn't __destruct is called even if reference count is gr then zero as a part
of script finalization? imo yes -- i tried this with echoing something
within singletons destructor (no invoke with explicit delete:-) and it
worked.
BR
a3c
- Original Messages -
Hallo everybody,
hope I am writing to correct mailinglist(^_^*)...
Absolutely!
I have troubles with sessions and descructor in php5. Can not set session
variable in destructor when it's called implicitly. Do You know solution
please?
I think problem is that session is stored before imlicit object
destruction
*doh*
example.php:
?php
session_start();
session_register(variable);
*Note* You don't need to use session_register() if you use $_SESSION.
In fact this probably isn't even doing what you think it is. Using
$_SESSION indexes is the preferred way to go about using sessions.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
}
}
$req = Request::getInstance();
$req-doSomeThink();
echo This should be hallo 2nd time: . $_SESSION[variable];//
unfortunatly this is not set
echo a href='example.php'Click and cry;-(/a;
// implicit desturctor call
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
?
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP] Re: Session variables are not stored when set in implicitly calledconstructor!??
Adam wrote:
Hallo again,
thank You for Your response.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
i agree that in *most* cases destructor should only clean up after object.
unfortunatly for request class there are few requirements:
1) must allow immidiate use w/o any explicit initialization or finalizaion.
e.g. at any file You can use only Request::getInstance()-isRefresh() /**
test if this request was caused by browser refresh */. this should be one
and only line (except for inclusion of request.php oc) referencing request
class -- no explicit call to Request::saveToSession() or anything ugly and
potentialy disastrous like that.
Well ok, but why can't you just have saveToSession() in the conditional
block?
?php
$_SESSION['Request'] = Request::getInstance();
if ($_SESSION['Request']-isRefresh() ) {
$_SESSION['Request']-saveToSession();
/* etc. */
exit();
}
/* Rest of script follows here */
?
IMHO the point of OOP is to keep each function split into the minimal
functionality that you need. This allows you to reuse code easier
because a function does only the *minimum* amount of work necessary
instead of extra (unintended) functionality.
2) must provide mechanism for generating per session uniqe request
identiers. now implemented as md5($_SESSION[next_reqest_id]++) not very
effective but handy:-P
The default session IDs aren't unique enough for you? Well then you can
use uniqid()
?php $sess_id = md5(uniqid(rand(), TRUE)); ?
3) must be serializable (this is why i can not put that session manipulation
at __sleep function)
these requirements (1,3) cast out __destruct, __sleep and explicit call to
some saveToSession function. do You have any other idea when to store this
information , please?
So... Request must be serializable? Forgive me but I don't see how this
is a problem. Perhaps someone else will understand what you mean here.
Do you mean that you need to serialize Request when condition in #1 is
true? If that's the case then you should be able to use the code block
above.
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
*doh* i don't know how could i coverlooke taht user reaction:-( thank You.
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
Isn't __destruct is called even if reference count is gr then zero as a part
of script finalization? imo yes -- i tried this with echoing something
within singletons destructor (no invoke with explicit delete:-) and it
worked.
BR
a3c
Yes, __destruct() gets called as part of the script finalization and
depending on your needs this might or might not be A Good Thing.
--
Teach a man to fish...
NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-generalw=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
LAZY |
http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins
signature.asc
Description: OpenPGP digital signature
[PHP] Re: Session variables are not stored when set in implicitly called constructor!??
Adam wrote:
Hallo everybody,
hope I am writing to correct mailinglist(^_^*)...
Absolutely!
I have troubles with sessions and descructor in php5. Can not set session
variable in destructor when it's called implicitly. Do You know solution
please?
I think problem is that session is stored before imlicit object destruction
*doh*
example.php:
?php
session_start();
session_register(variable);
*Note* You don't need to use session_register() if you use $_SESSION.
In fact this probably isn't even doing what you think it is. Using
$_SESSION indexes is the preferred way to go about using sessions.
// singleton for request
class Request {
function __destructor() {
$_SESSION[variable] = hallo;
The __destructor() method is supposed to be about killing the class
(Request). It's probably bad practice to be changing $_SESSION vars
inside of there even if that $_SESSION var affects your class. Here,
read this page and maybe it will make more sense to you:
http://php.net/manual/en/language.oop5.decon.php
Heck, look at the user contributed notes since one of them will directly
affect this idea of yours.
}
}
$req = Request::getInstance();
$req-doSomeThink();
echo This should be hallo 2nd time: . $_SESSION[variable];//
unfortunatly this is not set
echo a href='example.php'Click and cry;-(/a;
// implicit desturctor call
If the reference count for $req is greater than 0 (i.e. there is a
Singleton) then __destruct won't be called. And why should it be
called? Because, again, __destruct is for cleaning up the class while
the object is getting destroyed.
?
Thank You very much...
BR
a3c
--
Teach a man to fish...
NEW? | http://www.catb.org/~esr/faqs/smart-questions.html
STFA | http://marc.theaimsgroup.com/?l=php-generalw=2
STFM | http://php.net/manual/en/index.php
STFW | http://www.google.com/search?q=php
LAZY |
http://mycroft.mozdev.org/download.html?name=PHPsubmitform=Find+search+plugins
signature.asc
Description: OpenPGP digital signature
[PHP] Re: Session variables not unsetting
Security? Have you called session_start(); ??? /Peter Steve [EMAIL PROTECTED] skrev i meddelandet news:[EMAIL PROTECTED] Steve wrote: I'm having a problem with session variables. Never mind. Seems that the hosting company decided this week to switch from register_globals off to register_globals on. I'm not the first person to call them about this! -- @+ Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables not unsetting
Peter Lauri wrote: Security? Have you called session_start(); ??? Yeah - as I mentioned in the original post, all my pages start with that. I'm a little PO'd about the change to register_globals on. Alas, trying to switch it off in an .htaccess file causes a 500 error. That said, I never use variables passed by $_POST or $_GET without validating and all variables on the page are always initialised so I'm hoping the security exposure is minimal. -- @+ Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables not unsetting
On Monday 06 December 2004 22:50, steve wrote:
Yeah - as I mentioned in the original post, all my pages start with that.
I'm a little PO'd about the change to register_globals on. Alas, trying to
switch it off in an .htaccess file causes a 500 error. That said, I never
use variables passed by $_POST or $_GET without validating and all
variables on the page are always initialised so I'm hoping the security
exposure is minimal.
With register_globals enabled, the problem is not with the $_POST, $_GET etc
variables (although yes you should always validate data when they come from
untrusted sources). The problem is that malicious users can pollute your
namespace and if you do not initialise variables properly before using them
your application can be compromised.
For example, you have a flag ($admin) which you set to 1 if the person logged
in has admin privileges. If you don't initialise $admin and only do something
like ...
if ($user == 'admin' AND $password == 'password') {
$admin = 1;
}
// later in your code
if ($admin == 1) {
echo Hello admin;
} else {
die (Go away);
}
... it is all too easy for a malicious person to access your protected page
like so:
http://www.example.com/admin-page.php?admin=1
and they would have admin privileges.
If you had initialised $admin to some known, safe value before using it then
you have no problems.
So either of these would be fine:
$admin = 0;
if ($user == 'admin' AND $password == 'password') {
$admin = 1;
}
// or
if ($user == 'admin' AND $password == 'password') {
$admin = 1;
} else {
$admin = 0;
}
--
Jason Wong - Gremlins Associates - www.gremlins.biz
Open Source Software Systems Integrators
* Web Design Hosting * Internet Intranet Applications Development *
--
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
--
/*
Youth is a blunder, manhood a struggle, old age a regret.
-- Benjamin Disraeli, Coningsby
le,
*/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables not unsetting
Jason Wong wrote: With register_globals enabled, the problem is not with the $_POST, $_GET etc variables (although yes you should always validate data when they come from untrusted sources). The problem is that malicious users can pollute your namespace and if you do not initialise variables properly before using them your application can be compromised. As I mentioned, I always initialise variables. I'm no programmer, but it just makes sense to me that if a variable exists, it should have some sort of default value. -- @+ Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables not unsetting
steve wrote: Jason Wong wrote: With register_globals enabled, the problem is not with the $_POST, $_GET etc variables (although yes you should always validate data when they come from untrusted sources). The problem is that malicious users can pollute your namespace and if you do not initialise variables properly before using them your application can be compromised. On the contrary, with register_globals enabled, the problem *IS* with $_POST, $_GET etc variables being polluted! That is the very definition of the problem register_globals was designed to solve. Turning register_globals OFF simply corrals the pollution so that it's *ONLY* in $_POST/$_GET/$_REQUEST/etc instead of automatically being spewed throughout the global name space of all variables. If you blindly walk through POST/GET, or use extract on them, or do something that turns *EVERY* POST/GET entry into a variable, you might as well turn register_globals ON -- Otherwise, your OFF setting is only providing you with a false sense of security, which is worse than no security at all. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables not unsetting
On Tuesday 07 December 2004 01:32, Richard Lynch wrote: steve wrote: Jason Wong wrote: With register_globals enabled, the problem is not with the $_POST, $_GET etc variables (although yes you should always validate data when they come from untrusted sources). The problem is that malicious users can pollute your namespace and if you do not initialise variables properly before using them your application can be compromised. On the contrary, with register_globals enabled, the problem *IS* with $_POST, $_GET etc variables being polluted! I'm not sure I'm following you. Regardless of the register_globals setting, $_POST, $_GET and siblings has the potential to be polluted and data from them should be validated and sanitised. That is the very definition of the problem register_globals was designed to solve. ... flummoxed ... Anyway the way I see it is that the original intent of register_globals (and it being enabled by default in older versions) was a feature so that people can work 'directly' (as it were) with the request variables instead of having to use $HTTP_POST_VARS['myvariable'] etc. It was only when people realised that it could be a liability that is now disabled by default. Turning register_globals OFF simply corrals the pollution so that it's *ONLY* in $_POST/$_GET/$_REQUEST/etc instead of automatically being spewed throughout the global name space of all variables. If you blindly walk through POST/GET, or use extract on them, or do something that turns *EVERY* POST/GET entry into a variable, you might as well turn register_globals ON -- Otherwise, your OFF setting is only providing you with a false sense of security, which is worse than no security at all. This bit I follow and whole-heartedly agree with. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* When you are about to die, a wombat is better than no company at all. -- Roger Zelazny, Doorways in the Sand */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables not unsetting
Steve wrote: I'm having a problem with session variables. Never mind. Seems that the hosting company decided this week to switch from register_globals off to register_globals on. I'm not the first person to call them about this! -- @+ Steve -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session variables not recognized?
On Tue, 25 May 2004 08:36:37 -0700 [EMAIL PROTECTED] (Brian Dunning) wrote: The first line of my file is session_start(); but whenever I try to set or reference $_SESSION['anything'] I get: Undefined variable: _SESSION What's up with that??? what php-version do you use? thomas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session variables not recognized?
The first line of my file is session_start(); but whenever I try to set or reference $_SESSION['anything'] I get: Undefined variable: _SESSION What's up with that??? what php-version do you use? It is 4.3.2 on XP. I only recently installed it and this is the first time I've tried using sessions and variables on it, so it's entirely possible that there is a configuration problem. phpinfo() looks OK to me but I admit that I don't really know what to look for. Sessions are enabled, that's about all I can tell... :) - Brian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: session variables
Thanks for the suggestions, turned out to be a server setting the hosting compnay had set in the php.ini, see below: - session.cookie_domain = inweb.net.uk// this points to the hosting companies url by adding the following resolved the problem: - ini_set(session.cookie_domain, $domain_name) Works a treat now, the server was saving the session cookie for the wrong url and hence when the secoudn page was called in the same browser it wa not able to collect up the session variables as the domain names were different. Thanks again, Regards Charlie. Charles Collins [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have two test files running on a server, which is giving me a headache, due to the fact the session variables are not been maintained across the two pages. The server is running ... PHP Version = 4.0.5 register_globals = ON Session Support = Enabled session.auto_start = Off session.cache_expire = 180 session.cache_limiter = nocache session.cookie_domain = inweb.net.uk session.cookie_lifetime = 600 session.cookie_path = / session.cookie_secure = Off session.entropy_file = no value session.entropy_length = 0 session.gc_maxlifetime = 1440 session.gc_probability = 1 session.name = PHPSESSID session.referer_check = no value session.save_handler = files session.save_path = /tmp session.serialize_handler php session.use_cookies = On The two script files are as follows: - Page #1: ? session_start(); session_register(test); $test = Hullo World; print $test; // prints test ? Page # 2 ? session_start(); print $test;// prints nothing, zip! ? Can anyone tell me where I'm going wrong, works fine of test servers, etc., only screwed up when site was lauched. Thanks in advance ... Regards Charlie. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session Variables Disappear and Reappear
For those interested I was able to get to the bottom of this issue. My
hosting supplier uses multiple servers to do load balancing. As such the
folder in which the session variables were stored was stored in a /tmp file
on each of the servers. That explained why the session variables would
randomly disappear and reappear. It also explained why my single-server
test system experienced no problems. The solution was to set up a /tmp
folder for the session variables in my public_html folder. When I did this
everything worked perfectly.
I'm not a professional programmer. I started this website very recently on
behalf of a project we do at our church. I'd be interested in others
opinions and thoughts regarding how other hosting services handle this
issue. Should I have expected to create the /tmp folder within my
public_html folder or do other hosting services provide a different
approach?
Thanks and Happy New Year to everyone.
Jerry Kita
Jerry Kita [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
New to PHP and I've checked previous posts and haven't seen similar
problem.
Any ideas would be appreciated.
Have encounted an odd problem. Using session variables to allow users to
log
in and out of my site. I've created a test system on my laptop. Apache
2.0.48,
PHP 4.3.4, MySQL and Windows 2000. On my test system everything works
perfectly. Sessions are created and maintained as long as the browser is
open.
I can also destroy sessions.
However when I load everything up to my site via FTP the results are very
sporadic. Sessions seem to drop and reappear. While a user is logged in I
display a Logged in as: X message at the top of the page. I can
continually refresh the page and occassionally the Logged in as X
message will disappear showing the Please Login Form. If I refresh again
(without logging in) the page shows the user is again Logged in.
Here's the script that I use to log users in:
?php
error_reporting (E_ALL ^ E_NOTICE);
//check for required fields from the form
if ((!$_POST[userid]) || (!$_POST[password])) {
header(Location: Salkehatchie_Home.php);
exit;
}
session_start();
//connect to server and select database
$conn = mysql_connect(x.x.x.x, xx, x) or
die(mysql_error());
//echo Connection is $conn br;
mysql_select_db(xx_salkehatchie,$conn) or die(mysql_error());
//create and issue the query
$sql = select userid, password, privs from userlist where userid =
'$_POST[userid]' AND password = '$_POST[password]';
//echo USERID is $_POST[userid]br;
//echo PASSWORD is $_POST[password]br;
//echo SQL is $sqlbr;
$result = mysql_query($sql,$conn) or die(mysql_error());
//echo Result is $resultbr;
$rows = mysql_num_rows($result);
//echo Number of Rows are $rowsbr;
//get the number of rows in the result set; should be 1 if a match
if (mysql_num_rows($result) == 1) {
//if authorized, get the values set the $_SESSION Variables -- userid,
password and privs
$_SESSION[userid] = $_POST[userid];
$_SESSION[password] = $_POST[password];
$_SESSION[privs] = mysql_result($result, 0, 'privs');
//Direct user to members page
header(Location: Salkehatchie_Members_Home.php);
exit;
} else {
//redirect back to login form if not authorized
header(Location: Salkehatchie_Home.php);
exit;
}
?
I start off each webpage with the following script:
?php
//Check for existence of Valid Login ID
error_reporting (E_ALL ^ E_NOTICE);
header(Last-Modified: . gmdate(D, d M Y H:i:s) . GMT);
header(Expires: . gmdate(D, d M Y H:i:s) . GMT);
header(Cache-Control: no-store, no-cache, must-revalidate );
header(Cache-Control: post-check=0, pre-check=0, false);
header(Pragma: no-cache);
session_start();
if (isset($_SESSION[userid])) {
$validlogon = YES;
} else {
$validlogon = NO;
}
echo $validlogon //test to see if user has previously logged on
This all works perfectly on my test system but creates problems at my
site.
If anyone would like to see this for themselves go to the following site:
http://www.salkehatchiehuntersville.com/Salkehatchie_Home.php
and log in using test/test as userid/password. When logged in go back to
the
home page and then continually refresh that page. You will see that that
the
user moves in and out of a logged in status. This will also show up on
other
pages but since this site is under construction it's safest to stick to
the
HOME page.
Other possibly helpful information. Web Hosting site is BlueDomino.
Thanks for your help.
Jerry Kita
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session Variables
This variable is registered in the Session, and the variable isn't active
until the page refreshes. It's hard to explain. I thought I would try.
There are some things you can do. If you need the variable right away, you
can do this:
if (isset($HTTP_SESSION_VARS[user1])) {
$user1 = $HTTP_SESSION_VARS[user1];
}
else {
$user1 = $HTTP_POST_VARS[user1];
}
echo $user1;
Hope that helps. This is natural for sessions, but I have been in the
situation where I needed the session variable right away, instead of the
script's next activation.
Jed R. Brubaker [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
I have a quirky problem that should be a breeze for someone who is smarter
than I.
I have a script where I am registering a HTML form post variable as a
session variable and then echo it. In the real script I use it in a MySQL
query, but for the sake of this post, here is the script:
$user1 = $HTTP_POST_VARS[user1];
session_register(user1);
echo $HTTP_SESSION_VARS[user1];
This doesn't work, however, if I hit the refresh button the var
miraculously
appears!
What am I doing wrong?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session Variables
On Mon, 25 Mar 2002 18:18:33 -, [EMAIL PROTECTED] (Chad Gilmer) wrote: Hi There, I am a beginner to PHP and I am tring to use session variables on my site. I am trying to use Session Variables in PHP on the iPLANIT.tv site When I use the following code: ?php $ses_counter++; session_register(ses_counter); ? I get the following error Warning: Cannot send session cookie - headers already sent by (output started at /home/iplanit/public_html/php/login.php:8) in /home/iplanit/public_html/php/login.php on line 11 Warning: Cannot send session cache limiter - headers already sent (output started at /home/iplanit/public_html/php/login.php:8) in /home/iplanit/public_html/php/login.php on line 11 Any Ideas??? Cheers Chad put the session_register() in front of the code. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: session variables in functions....
Make it global or pass it as an argument:
function CurrentLang(){
global $HTTP_SESSION_VARS;
$language = $HTTP_SESSION_VARS[LangID];
echo($language);
}
Or:
function CurrentLang($HTTP_SESSION_VARS){
$language = $HTTP_SESSION_VARS[LangID];
echo($language);
}
--
Julio Nobrega
No matter where you go, this.
Wim Van Houts [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Somebody knows why I cannot reach the $HTTP_SESSION_VARS in a function
For example, why does this not output the en-US string three times:
?
session_register(LangID);
$HTTP_SESSION_VARS[LangID] = en-US;
echo($HTTP_SESSION_VARS[LangID]);
echo(**);
function CurrentLang(){
$language = $HTTP_SESSION_VARS[LangID];
echo($language);
}
CurrentLang();
echo(**);
echo($HTTP_SESSION_VARS[LangID]);
?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Re: Session variables
You'll have to define what you mean by "currently online". Do you mean actually waiting this moment for HTML to finish streaming to their browser? Or do you just mean, in my session files and not timed out yet? Probably the easiest way to do that would be to use http://php.net/session-set-save-handler You could wrap some book-keeping around PHP's internal FILE sessions, or store them in MySQL and then your simply need to query how many rows there are in the table. -- WARNING [EMAIL PROTECTED] address is an endangered species -- Use [EMAIL PROTECTED] Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm - Original Message - From: Ing. Lalka Peter [EMAIL PROTECTED] Newsgroups: php.general To: [EMAIL PROTECTED] Sent: Friday, September 07, 2001 3:22 AM Subject: Session variables Hi! I want to know how many users are currently online at my site. How can I get this info from php? Can I? Thank you for answer. Barno -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
