Session recording issue moving from Apache to IIS6 2

[spamjim]

I'm moving a web app that works successfully in Apache to an IIS server controlled with a Plesk interface.

I'm having trouble with a login page that has a form function that points to the same login page. If the login page reloads with the right form submitted value, it writes session data and uses the header command to jump to another page in the site. The jump to the other page is happening but I am not seeing any session data recorded and the other page is not reflecting a logged in status.

My mind is fried over this stumbling block. Are there any ideas to trigger my mind into getting session data working? I know sessions are enabled as I have another app running on the same server (and same hosting account) that uses sessions successfully.

 

[DonQuichote]

Well, check that sessions work. Sessions are largely done by PHP, needing very little from the web server. There are a few things that could be wrong:
- No session cookies or session ID fields are sent for whatever reason. This is easy to check with Firefox and LiveHTTP headers plugin. IF there are no cookies, check php.ini.
- The sessions cannot be written because of lacking disc space or insufficient rights for the server. IIS runs the page under a user, which must be able to do the work. If that user cannot write to the session directory (usually the system's temp directory), no session data will be stored.
- It could be (but it is unlikely) that special apache headers or functions are used by the PHP pages.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[jpadie]

often it's because the php.ini specifies a session save location that does not exist.

and i believe that typically IIS runs under the permissions of IUSR_[MACHINE_NAME]. of course it is possible to change this.

 

[spamjim]

Thanks for the thoughts.

I've successfully created a new 10 line PHP page that shows sessions are working elsewhere.

The troubled log-in page in question calls another file to act as a template.

require 'header.php';

If I comment this line out, the login page works fine (just unstyled without the template include). 'header.php' just prints basic HTML to draw a table so I am lost why IIS would be bothered by this include.

I'm careful not to send anything to the browser before sessions and cookies are handled. Is there any other quirk of IIS that I could be missing?

 

[jpadie]

have you got error reporting and display turned on?

 

[DonQuichote]

As I said, don't point at the server for these "errors". Like jpadie asked, what errors, warnings and notices do you get?
They should always be ON on your development machine (and off on the live server).

One reason for apache NOT to fail on the same project could be that PHP on the apache server was configured to use caching. That means that the header content would be cached and you still had the opportunity to set a cookie, even though you provided output (but that output was not yet sent but only cached). Relying on caching for these purposes is unreliable though. So it could very well be that you now discover a bug that was "by accident" suppressed on the apache server.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[spamjim]

Thanks for the help. Apache was indeed being extra forgiving when I should have known better.

When session_write_close() is added before header(), everything works again (or as it should have originally).

//write session stuff
session_write_close();
//then redirect to new page
header("Location: $strPage");
exit();

This is discussed/explained at

http://bugs.php.net/bug.php?id=14636

 

[jpadie]

you need to use session_write_close typically only when there is a race condition. this is most likely to happen on local servers. the issue is that you are retrieving the next page (and thus opening a session) before the previous script has finished saving the previous session. thus there is a race condition on the file-system between read/write accesses. forcing a session_write_close avoids this but, in practice, it should never be an issue outside of lan environments where considerable quantities of data are being saved.