Patreon / patreon-php

Interact with the Patreon API via OAuth
Apache License 2.0
144 stars 41 forks source link

Developing using the patron api without beeing a creator yourself #18

Closed Ansraer closed 7 years ago

Ansraer commented 7 years ago

I am currently working on a small php project to limit access to parts of a website to patreons for a friend who is considering to become a creator. The problem is that I myself am no creator and have no access to the documentation or an account to test my code with. Would it be possible for me to somehow read the documentation? And is there a dummy creator account with dummy patreons we can use to test our code? Even if I were to wait for my friend to setup his campaign it would be kind of difficult to simulate different situations without having access to a few of his patreons.

Ansraer commented 7 years ago

Ok, so I wrote to the support and they told me that I can become a creator without publishing my site to test the api.

I now finished my first version (Still looking for a way to host my site so that I can get a fix url) but there is one thing I am unsure about: I can use the access token to get all of the users information when they log in on my site. A month later I can use the refresh token to get a new access token. But do I even need it? I mean, once I have their id I can just check the pledges and compare the ids to the already saved user ids. As long as user ids do not change and they are show to me when I fetch informations about my campaign Thats really all I should need, right?

UmrenTV commented 7 years ago

Hey Brother, I am very much interested in this as well myself. I can help u develop this stuff, since i've been desperately looking for someone that is able to work this with me, since I am not really a PRO when it comes to API implementation.

If u are up for a challenge, maybe teaming up with me, maybe earning a buck or two as a team, etc etc... let me know.

I am open to Discord / Skype anytime u feel comfortable with. I wanna implement that on umren.tv that I've designed it from scratch, with 0 knowledge, so I am passionate learner of all these stuffs step by step, with as little time as available to me.

Cheers and Update this thread please, I am follower of yours since this point on! :D

UmrenTV commented 7 years ago

oh and also... I would really say u don't need to refresh the token every month... but in case someone un-pledges, and some changes in user info happens, modify pledge, etc you might want to re-fetch all the info from patreon, and for that u might need refresh token. Correct me if I am wrong but I've been thinking the similar stuff as you are.

rluders commented 7 years ago

Guys, I'm working in the similar solution. I'll start to do it right now. Any advice? It's really necessary to update the token every month? I think that's not a problem at'll but if it is necessary I'll need to find a quick way to do it without every month change it on code.

UmrenTV commented 7 years ago

rluders - Cheers for jumping into this brotha... well... I am not professional coder to be honest... but I would imagine, since there is date of pledge created (I think) in Patreon JSON return... you can add into the code to check every 30 days on the same date, for that Patreon supporter if it's still Patreon or not? I am not sure, but that is 1 way, if possible. I was thinking of doing it with Cron Job from the server but it might slow down the website, if u got a lot of Patreons... (which I don't as many) ... but just as an idea.

21echoes commented 7 years ago

Hey everybody! The access_token refresh_token system is a core part of the OAuth 2.0 spec, which is what Patreon's platform conforms to (as do Facebook, Medium, Google, etc.) We conform to the spec for two primary reasons: 1. We think the spec is well-designed and more thought-through than anything we'd invent from scratch, 2. Libraries and skillsets that developers have acquired through interacting with other platforms can be leveraged for interacting with us.

The specific reason for a refresh token is: if an access token is compromised, because the access token is short-lived, the attacker has a limited window in which to abuse it. This is similar to how most websites grant you a short-lived cookie, and require you to refresh your cookie token with your username and password. Strategies like this are especially helpful with situations like e.g. the recent CloudBleed bug, which compromised HTTPS traffic of a large portion of the internet. Because our clients talk to us using the access_token, we are able to expire the access_token early and trust that clients have code to acquire new ones using the refresh_token.

As far as a strategy for using the refresh_token -- we highly recommend using an error handler strategy, as per our example code. This obviates the need for a cron job, and has the added benefit of handling early expirations the same as routine expirations.

As the original issue -- how to develop the API without yet being a Patreon creator -- has been resolved (become a creator on Patreon, but don't launch your page if you don't want to have a creator page), I'll be closing this issue.