Sessions x Firewall/Proxy

[lobobr]

Greetings.

I'm having some odd problems with a client that tries to access the company site by clicking on a link in an e-mail.

The client's firewall/proxy simply blocks the page that sets the session variables and displays a balnk screen on the client's browser.

I'm looking for a (miracle?) solution that I can use without having to mess with the client's firewall (because he won't let me).

Here's how it should be:

1) Client receives and e-mail with a link that has, among other parameters his username and encrypted password, i.e.:

http://www.mydomain.com/entrance.php?l=myname&p=mypass&pid=9921&title=test

2) The entrance.php script fetches the parameters and try the "l" and "p" against a postgres db.

3) In the case that the user's login and pass are correct, the script let him pass, by starting a session and registering several variables with values fetched from the db.

4) The script opens a popup window with the product the client "was interested in", defined by the "pid" parameter.

You can say "how do you know that your problem is the session?"

I'd say "Because I've made several tests, including passing parameters directly to the script that generates the product page and all other tests works, except when trying to use the script that sets the session. Besides, if I comment out the session comands it works."

You can also say "How in the world a proxy firewall can mess up with some PHP code, wich only runs on your server?!"

I'd say "You got me there, because I don't use session cookies and I'm very impressed with this proxy firewall power."

So, here I am, folks. This is my dilemma: I can't make any changes in the client's firewall and I can't think of something that can solve the problem.

Please, can anyone help me out here?

Best Regards,

[Rex__]

I'm no expert, but since you kindly replied to my post, here goes...

I bet the problem is a PHP bug with using the proxy. Session handling is always unpredictable when the client is behind a proxy server, since all the clients can end up being indistinguishable, and sessions need to be unique.

PHP won't set the cookie on the client if it client can't accept a cookie. Instead, it carries it in the query string. Ask the user if the PHP sessionid is shown in the query string. This should tell you that the script has at least set the session. If there is no sessionid in the query string, the cookie still may have been set on the user's computer. I would try accessing that cookie with another script to test it's existance.

If you don't have access to the user's machine, why not just start over with user-defined query string session variables and parameters? You obviously are very familiar with them already. Everything you described can be done that way.

Since PHP isn't giving you an error, I think it's a bug with PHP setting the cookie. Another possibility is that particular user's browser might be faulty. Ask the user to wait 30 seconds when the blank screen appears. This is the default timout duration for a script. If the script is trying to set the cookie, and waiting for it to finish, the script should eventually time out. If this happens, the problem is the user's browser not being able to set the cookie properly.