JavaScript is required to use Bungie.net

Forums

originally posted in:BungieNetPlatform
8/20/2015 8:44:55 AM
5
When I wrote the library I didn't really intend for it to be used in that way because I don't consider it safe to be handling other users' details, including cookies. Regardless, PsnUser inherits from [url=https://github.com/dazarobbo/BungieNetPlatform/blob/master/src/PlatformUser.php]PlatformUser[/url], so you can use all the methods defined there. The one you will probably want to make use of is [url=https://github.com/dazarobbo/BungieNetPlatform/blob/master/src/PlatformUser.php#L72]getCookieJar[/url]. You'll need to serialise it (or just the cookies you're interested in) then store the result in some persistent area ($_SESSION, disk, etc...). Later when you need the cookies again, do the reverse - read the result from where it's stored and add them to the CookieJar.
English

Posting in language:

 

Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

  • Thanks, really appreciate you taking the time to help out a poor old confused front-end dev. That makes a lot more sense, I guess I was assuming the cookiejar was taking care of the session stuff itself. When you say you didn't intend for it to be used in that way, what would be a better way of using it? Like I say, this app probably won't be used by anyone other than myself, so I guess the usual safety concerns aren't too much of an issue, but I'd still like to learn the best way to do things if I'm going to try to get to grips with back-end. Thanks again.

    Posting in language:

     

    Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

  • As far as using it to manage other users' details, there is no other way than to handle their login details and perform authentication on their behalf (which is monumentally unsafe for all parties involved) . OAuth is the ideal secure mechanism for this issue which I hope is supported one day. As for using it for yourself, I kind of imagined a case where someone would be interested in running their own local program for some purpose (eg. automation) or grabbing some default information you could only acquire with an account then publishing it publicly.

    Posting in language:

     

    Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

  • Edited by That Griff: 8/21/2015 12:31:05 PM
    Thanks again, this is all making a lot more sense to me now. I just have one more question if that's ok? Is there any reason why it would be bad to just take the platformUser and store it in the session then set the user from that when needed? It seems to work fine, I'm just not sure if there's some argument against it that I'm not aware of.

    Posting in language:

     

    Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

  • You [i]could[/i] do that, but there are a couple reasons against it I can think of. 1. If you try to assign a non-scalar type to $_SESSION, I think PHP will try to call serialize() on it internally when it writes the session variable to disk or wherever else. This might not work for a couple of reasons: 1) IIRC, PlatformUser doesn't implement Serializable, so I think it's going to give you a serialised string with all public, private, and protected members, which could be [b]very large[/b] and might impact on performance and scalability in particular if you're dealing with a lot of users; 2) I don't know whether a derived PlatformUser instance will properly deserialise to the appropriate derived class (ie. XboxUser or PsnUser). Since it doesn't seem to be a problem for you though you can probably just ignore this one. You might want to try setting the object to $_SESSION in one request, then var_dump()ing it when you read it back out in another. It might have all the variables but be considered an stdClass instead. 2. If it's at all still an issue, storing an XboxUser or PsnUser instance as a $_SESSION variable might be further security issue. Since both types contain Email and Password members, if you set the whole object as a $_SESSION variable, those members will no longer be contained to the PHP/web server process; they'll be serialised to disk in plaintext, which is probably not what you want. Give it a try and open up the [url=http://us.php.net/manual/en/session.configuration.php#ini.session.save-path]file(s) where sessions are saved[/url]. You should see your email address and password. Remember too that those values will exist as long as the session is considered valid and PHP is yet to clean them up.

    Posting in language:

     

    Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

  • Ah cool, yea that makes sense, thanks a lot for everything, it's been a great help.

    Posting in language:

     

    Play nice. Take a minute to review our Code of Conduct before submitting your post. Cancel Edit Create Fireteam Post

You are not allowed to view this content.
;
preload icon
preload icon
preload icon