Need example code

edited December 2013 in Developers
The example code in PHP-SDK/examples glosses over how to authenticate, how to get access tokens and refresh tokens. Can somebody talk me through these things? I'm an experienced programmer but new to PHP and I've never touched oauth before.


  • edited December 2013
    I'm not sure if there are any specific authentication examples set up, but it is a fairly straightforward OAuth2 authorization code setup to grant the access/refresh tokens, so should work with existing OAuth2 client libraries out there to get an idea of how it works.  I've also started updating the docs with a bit of an overview on authorization at:
    Let me know if there's anything unclear that could be tightened up, or you're interested in going over a basic setup in another language.

    I might put together something of more of a comprehensive update usage example at some point in the future if I get a chance.

  • That document helps a lot, thanks. I gather from looking at CheckfontAPI.php that you take care of that for me as long as I provide an implementation of store().

    When it says to store that refresh_token in a "secure source", what sort of threat are you protecting against? Are you worried about somebody coming in through the web or are you worried about somebody who has access to the entire file system? I mean, is just storing it outside of the DocumentRoot sufficient, or is there some other best practice? I'm going to be using it on a Wordpress app on a hosting site, so I'm constrained about what I can install or count on being installed.

  • edited December 2013
    Yep, it should cover the authentication that needs to be done.

    The major point you want to protect against is storing the tokens in plain text anywhere that can be accessed by anyone other than your application; so yes, you'll want to keep them out of the document root, and away from any shared accessible area.  Without your application's consumer key/secret combo, the refresh token is absolutely useless, but the access token can be used to directly access your resources until it invalidates.

    I would typically suggest you store the tokens in a database (such as your Wordpress db) - this way, they're easily accessible to your application, and (for example) could easily be linked up to particular users in your own system if you allow individual staff members to log-in to their Checkfront accounts.  They are replaced on a regular basis as long as your application continues to be used, so pretty much any basic database or key store is ideal to ensure it is stored reliably - if you prefer to use something like a SQLite database in your filesystem, just make sure it can't be accessed by anyone.

    In the case of staff logins, you could store the access/refresh tokens directly as cookies on the client end, but this does add a bit of a vulnerability to your system if your staff member is running on an unsecure connection/system and/or your server doesn't run SSL.  Effectively it adds a remote possibility of the token being read from the clients browser, or intercepted between the client and your server since it would be sent with every request.  Granted, they would only be able to steal the access token and use it until it expires, and they'd have to know how to manipulate the API, but it's worth considering.
This discussion has been closed.