My site takes two tries to decode

I'm sending an encoded string as a url like


checkout.php?string=ehotenMLkelskEIdkfjLOSLjdlelfenSeksl,

the string is decoded by a function that basically;

base64_decodes, stripslashes, gzuncompress, and unserializes the string.

To give me the information I need to use in a query to display their shopping cart.

However, some people testing it get my error page I created if there is something wrong with the query so I know the query is not firing using the decoded information. BUT, when the test subjects go back a second time, everything works fine.

I've only tested it online from my development computer using chrome, mozilla, and IE and I've had no problems.

Is there something with those decoding functions in php that require people to use them once before they work? I thought about removing the gzcompress and serialize functions in the original encoding of the string, but I thought I'd give ozzu a shot before I change all my encryption functions so I can maybe get some better suggestions at what to look at.

When you say "go back a second time", do you mean immediately refresh the page or report it to you and go back an hour later to try again ?

Something tells me I would want to start by looking at session management.

Is it possible these people are entering through somewhere that fails to start a session that all of this stuff might need ?

Maybe they're saving the URL and coming back to it later after a session has expired ?

Actually that's what I thought that the people were going back to the url later.

When the people went back a second time they logged in again. They went all the way back and re-did the cart. I don't know if just refreshing the page might of worked. I can't reproduce the problem on my end cause it works for me.

I have a flash swf they log into and build a shopping cart. Then a flash button they click gets the URL checkout.php in _self and strings the url checkout.php?string=x

SO, x comes from the flash. It's not really a session ID but just their member id and logintime in order to pull their most recent cart contents.

Hey Joe, Can I PM you the site url and give it a test just to see if you can see the review cart page?

Feel free to throw it my way too, if you'd like. Won't hurt my feelings if you don't want to, though.

Sure, I'll take a look.

Got it fixed. Thanks you two. That was the information I needed but the testers are just ordinary folk and couldn't explain what was going on.

Problem solved.

Was it the empty cart thing ?

yes, the string was not populated if the user went to the login immediately following registration. It had nothing to go with the encryption methods.

I was way off and really racking my brain. Thanks for your reports.

Glad you found it. Figured that had to be the cause given the blank var on the GET. Happy to help out.