NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
[resolved] Problem with PHP sessions


Joined: 10 Feb 2004
Posts: 93
Reply with quote
Ok, I have been using PhpEd since version 3 and have never touched the Debugger until now. I know, I know... what was i thinking?!?!?? So first, the debugger is simply AMAZING! dmitri, you have done an EXCELLENT job.

I'm using PhpEd (registered) v5.0.1 (build 5028) with all the defaults. The project is set up with Run Mode as System Default. I'm running the debugger locally. Everything seems to be working ok... as long as I'm on my index.php page.

When the user posts his/her username and password, if the credentials are correct, a session is started, several session keys are set and they are sent (via header->location) to a second page. If they fail, they stay on the index page. On this second page, the session is started, and then the session keys are checked. based on the values of those keys, different information is presented. When I run everything through the debugger, the session is being "lost" when I get to the second page. I've tried it using the embedded Mozilla browser, the external mozilla browser and the external IE browser. If I look in my Sessions path folder, I can see that the session was created, and that the session file contains the correct information, but I also see that it is creating a whole new session id for the second page. For some reason, it's as if, when using the debugger, the session id being sent by the browser isnt being received by the php interpreter. I have the exact same code running on my development (remote) server, and it works exactly as I expect it to (ie the session data that i set at the end of index.php is available on the 2nd page after i start the session).

I've set debugger.enable_session_cookie to ON, have "Debug Session" enabled in the debugger options, and have added ?DBGSESSID=1;d%3D1 to the header redirect, but so far, nothing seems to have worked.

Here is what phpinfo shows for the debugger's settings
Quote:
Version 3.2.2
Linked as a shared library.
Dbg SSL not available
Dbg ip security enabled.
Profiler enabled
Target PHP version 4.4.x
Server API CGI/FastCGI
Extensions API 20050606
Modules API 20020429
PHP API 20020918

Quote:
debugger.enable_session_cookie On On
debugger.enabled On On
debugger.fail_silently Off Off
debugger.hosts_allow protected value protected value
debugger.hosts_deny protected value protected value
debugger.ignore_nops Off Off
debugger.JIT_enabled Off Off
debugger.JIT_host clienthost clienthost
debugger.JIT_level 3 3
debugger.JIT_port 7869 7869
debugger.net.chunksize 48000 48000
debugger.net.maxpacketsize 4096000 4096000
debugger.ports protected value protected value
debugger.profiler_enabled On On
debugger.session_nocache On On
debugger.timeout_seconds 300 300


Any ideas on why I cant access my session data on subsequent pages?

My next question is more of a logistical question... I have a development server and a production server that I have access to. However, the sys admins will not install DBG on the development server for me (I work for a Uni of which there are 1000's of people on these servers). So I am having to run the debugger locally (as I mentioned above). My biggest hurdle right now is include locations for the local debugging (XP) versus remote servers (RHE4). Currently, I have my apps set so that it checks the server's ip address and if it is 127.0.0.1, points my includes to local directories, otherwise points them to the directory locations on the remote server. This way, my code is the same both locally and remotely, and I'm only having to work on one set of files.

Is there a better way to handle this? I'm sure I'm not the only one who has had found themselves in this situation, so I'm more than open to other suggestions...
View user's profileFind all posts by gilzowSend private messageAIM Address
Site Admin

Joined: 13 Jul 2003
Posts: 8344
Reply with quote
Quote:
When I run everything through the debugger, the session is being "lost" when I get to the second page.

Please do not mess debugger sessions with php sessions. They are completely different matters.
What you're talking about is PHP session. If you do not start it explicitly, you need session.auto_start setting to be turned on in php.ini. Please check with phpinfo() output.

Debugger session is intended to continue debugging upon navigation from a page that was debugged, nothing else.

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 10 Feb 2004
Posts: 93
Reply with quote
dmitri wrote:
Please do not mess debugger sessions with php sessions. They are completely different matters.

got it.

dmitri wrote:

What you're talking about is PHP session. If you do not start it explicitly, you need session.auto_start setting to be turned on in php.ini. Please check with phpinfo() output.


Yes, the session is started by a custom session handler, and I've walked through and know that it has been called correctly. And if I run it locally and not through the debugger, the session is restored successfully. As I mentioned earlier, the same script is being run remotely and works correctly. There is something when the script is called with the debugger that is preventing the session id from being passed from the browser back to the php interpreter.
View user's profileFind all posts by gilzowSend private messageAIM Address
Site Admin

Joined: 13 Jul 2003
Posts: 8344
Reply with quote
Quote:
the session is started by a custom session handler

if you have a simple script that will replicate the problem and you submit it there or send through Contact Us page, I'd highly appreciate it.

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 10 Feb 2004
Posts: 93
Reply with quote
ok, i dont know if something has changed between when i wrote the original post, or i dreamed the whole thing, but the session data is not being carried to subsequent pages whether I'm running the debugger or not. After about two hours of checking, I finally discovered that it had to do with my use of
Code:
ini_set('session.cookie_domain',APP_DOMAIN);

in my session wrapper function. I had APP_DOMAIN set to 'localhost' if I was running locally, but it didnt like that. Sorry for the false alarm. Embarassed

Is there a way to see the current value of your constants during debugging, short of adding them to the watch list? I was thinking that I could hover over them like I do a variable and a small pop-up would display its value, but nothing happens for constants.

Which brings me back to my second question from my original post: is there a better way to handle this situation? Having to constantly juggle whether I'm running locally or not is becoming increasingly complex. I'm open to ANY suggestions that would make this easier....
View user's profileFind all posts by gilzowSend private messageAIM Address
Site Admin

Joined: 13 Jul 2003
Posts: 8344
Reply with quote
Quote:
Is there a way to see the current value of your constants during debugging, short of adding them to the watch list?

you may want to make get_defined_constants() call in the Immediate window or add this call to Watches

Quote:
Having to constantly juggle whether I'm running locally or not is becoming increasingly complex

Why do you need to change 'session.cookie_domain'? If you use cookie path =/ and empty domain, all the cookies you set will work for all the URLs inside current domain. I think that the only reason to use 'session.cookie_domain' is to have the same cookies to work for say www.nusphere.com and forum.nusphere.com ('session.cookie_domain' = nusphere.com) but it's rarely needed.
Finally, you can add somehostname.somedomain.somezone to c:\windows\system32\drivers\etc\hosts, for example:

127.0.0.1 localhost myhost_mydomain_com

and work with http://myhost_mydomain_com as if it were a really registered host

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 10 Feb 2004
Posts: 93
Reply with quote
dmitri wrote:
you may want to make get_defined_constants() call in the Immediate window or add this call to Watches


ok, I'll give that a try tomorrow.

dmitri wrote:
Why do you need to change 'session.cookie_domain'? If you use cookie path =/ and empty domain, all the cookies you set will work for all the URLs inside current domain. I think that the only reason to use 'session.cookie_domain' is to have the same cookies to work for say www.nusphere.com and forum.nusphere.com ('session.cookie_domain' = nusphere.com) but it's rarely needed.


unfortunately, that's exactly my situation. My apps all run on subdomains of the missouri.edu domain, so I have to specify the cookie_domain. I dont want the cookies to be accessible anywhere else on the missouri.edu domain except specifically the domain the app is running at.

dmitri wrote:
Finally, you can add somehostname.somedomain.somezone to c:\windows\system32\drivers\etc\hosts, for example:

127.0.0.1 localhost myhost_mydomain_com

and work with http://myhost_mydomain_com as if it were a really registered host


I hadnt even thought of that. good idea. I'll give that a shot tomorrow as well.

Thanks dmitri!
View user's profileFind all posts by gilzowSend private messageAIM Address
Site Admin

Joined: 13 Jul 2003
Posts: 8344
Reply with quote
Quote:
unfortunately, that's exactly my situation. My apps all run on subdomains of the missouri.edu domain, so I have to specify the cookie_domain. I dont want the cookies to be accessible anywhere else on the missouri.edu domain except specifically the domain the app is running at.

Maybe I'm wrong, but if you don't specify cookie.domain, cookie will work for the current HOSTNAME (FQDN) only. For example if the cookie issued from somehost.mywebserver, it won't work for someotherhost.mywebserver even though the hosts are from the same "domain" in DNS terms. At least I checked with www.nusphere.com and didn't see cookies the browser got from forum.nusphere.com

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website
[resolved] Problem with PHP sessions
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic