Jump to content

Assigning class instance to $_SESSION member for API callback


thescientist

Recommended Posts

BackgroundI'm not sure if any of you are familiar with the Paypal APIhttps://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference Just looking for advice in best practices, security, technical, etc, context regarding the topic title. FlowAs part of the Express Checkout flow, after a user chooses to checkout with Paypal from my clients site (by adding to cart from products in the 1000BC Store)http://www.1000-bc.com/products.php I make an AJAX request to the server to a PHP script which creates an instance of a Paypal class I created, populates it with the products and their properties (amount, description, etc) and I make a method call which upon success, returns a TOKEN I can use to redirect the user to paypal's site so that they can initiate the Express Checkout flow (i.e. review their order, login, pay, etc). After this, the user is redirected back to my site, to a separate checkout page, which handles the follow up methods that I need to call/make against the Paypal API in order to complete the transaction. The QuestionAfter the first AJAX request is made and I get the initial success TOKEN, I save the Paypal class instance in $_SESSION so that I have access to the classes state on the checkout page. Per paypal's recommendation, they suggest that for the follow up calls, the same information should be used as in the first call that returns the TOKEN. Rather than recreate the class on the checkout page and repopulate it again, is saving the class instance in $_SESSION okay? The only edge case I can invision is the user taking so much time checking out with Paypal that by the time they are redirected back to my site, their $_SESSION may have expired. Thoughts, advice?

Link to comment
Share on other sites

Hi I haven't used pay pal in a long time I don't really know what the best way would be. I just wanted to say that I had a program where expiring sessions were a problem and I created a little javascript that would over take their screen if they were idle too long and ask them to type their password in to refresh the sessions and it had a count down of 2 minutes which would log them out if they didn't respond.

Link to comment
Share on other sites

thanks for your reply. Currently, everything is working well, and the client hasn't reported any issues about expiring sessions per se. I guess technically the issue is API agnostic, as my intention was merely to add context to the question, so theoretically it could be any API that behaves in a similar fashion. Edge case aside, was just curious what member's thoughts/opinions where on the technique implemented.

Link to comment
Share on other sites

To avoid any session issues, I'd save the info in a database.In any case, I don't like serializing and unserializing objects... I feel like a necromancer every time I do it: It looks cool, but I'm dealing with remains.No, I prefer doing it Dollhouse/"ghost in the shell" style - store the essence, recreate from it in accordance to the new requirements... like a boss! :P

Link to comment
Share on other sites

Well, as part of the callback I do return the productId's in the URL, so I can always use those to re-pull the information from the database to try create the class instance again and do the follow up methods that way. As I write this, I think I am already getting the info from the DB anyway to populate the checkout page with their order summary, so the general foundation may already be there. Cool beans, thanks for all the feedback.

Link to comment
Share on other sites

I don't mind serializing objects, for example in the case that I have a user object for user data. Just assign a __sleep and __wakeup method for connections and resources

Link to comment
Share on other sites

Just assign a __sleep and __wakeup method for connections and resources
That's exactly the point at which the necromancery occurs. The point at which things feel ugly... You're euthanasing the object ("making it sleep" as it were ;)), and then resurrecting it from the grave that is a single piece of plain text. :lol:
Link to comment
Share on other sites

I don't mind serializing objects, for example in the case that I have a user object for user data. Just assign a __sleep and __wakeup method for connections and resources
http://php.net/manual/en/oop4.magic-functions.phpinteresting. definitely something to keep in mind. thanks for the pro tip Ingolme!
Link to comment
Share on other sites

That's exactly the point at which the necromancery occurs. The point at which things feel ugly... You're euthanasing the object ("making it sleep" as it were ;)), and then resurrecting it from the grave that is a single piece of plain text. :lol:
other than your mystical intuitions, lol, are there actually any legitimate, specific downsides to these magic functions?
Link to comment
Share on other sites

OK, in more serious terms... the fact that you're recreating the original conditions seems troublesome to me... what if the environment in which you're executing __wakeup doesn't need the new connection? You're establishing it anyway for the sake of having the object... and what if the new connections/resources you're binding the object to don't actually make sense in light of the whole sleep/wakeup procedure (e.g. if in the object you're keeping some sort of log of network bytes that the connection consumed thus far)? Sure, you can take care of such edge cases in the magic methods, but that would likely make the object behave in a counter intuitive way after it undergoes a sleep and wakeup.If your object is just a convenience wrapper for what you could otherwise write down as an associative array containing only scalar values... sure... serialize away. There's nothing that could go wrong. But when you reach a point where you need __sleep and __wakeup (i.e. when your object contains references to resources and/or non-serializable objects), you're taking the responsibility of ensuring smooth serialization and unserialization, which means potentially putting up with the above caveats.

Link to comment
Share on other sites

I see. As with anything then in our field, there is appropriate use case for something, but it seems, after reviewing my implementation and thinking about it some more with the help of the discussion here, I think I can see where I can get away without have to save the class instance at all, given the way that my checkout page works. (pulling the items from the database anyway to display in a purchase summary/review and not having to rely on the classes previous state for that). It would certainly eliminate the requirement for a dependency on the classes state, which in this case, is a good thing, as it will make my class more flexible. Thanks for all the comments and feedback. I think I will do a little refactoring over the weekend. Good to know about the magic functions though.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...