That seems to be a bit of a privacy concern if all the user has agreed to is their email to being shared?
I was looking for a way to see if the user is an active patron of my creator account, without having to iterate through all of my members with the API each time someone auth’d; and ideally without having access to their history of memberships to other creators.
Am I doing something incorrect? Any help would be appreciated. Thanks!
Authorising with only the identity scope (not including identity[email]) allows me to get the email off the identity endpoint with fields[user]=email, yet the docs say:
If you have the identity[email] scope, you will also get the user’s email address. You will not receive email address without that scope.
I replied about scopes in a DM, but tl;dr I see two options
the correct scope was not requested during the auth flow and both - identity and identity[email] are set.
the creator token was used to make the identity call. There are two types of tokens - creator token (available at Patreon Platform ) and user token received through the oauth authorization flow. The creator token has same full access as a regular creator account - you should be able access email the same way as if you accessed the audience relationship manager at patreon.com/members
I was looking for a way to see if the user is an active patron of my creator account, without having to iterate through all of my members with the API each time someone auth’d; and ideally without having access to their history of memberships to other creators.
The three options here would be to:
hit the /oauth2/v2/members api and iterate over the member list (using creator token)
hit the /oauth2/v2/member/<member_id> api and check the member status, if you’ve previously persisted the member id (using creator token)
hit the /oauth2/identity API (using the user token)
EDIT: I just realised you mentioned being able to see other memberships too. This is most likely happening because of using the creator token form Patreon Platform when accessing /identity - this will list all the creators (your) memberships. If you would use a user token, it should not return other memberships.
Thanks to @noertap we were able to work out the issue.
It turns out that when you change the scope attribute on your authorization call, it is APPENDED to any previous scope attributes that have been set. It doesn’t override.
So during initial testing I had a more permissive scope, and logged in with my test account. Then after reducing the scope (and the permission modal showing the lowered permissions), my app still had access onto the original scope and this new one through the access token Patreon provides.
Noertap is going to see if the documentation can be updated around this so it’s clearly stated.
Something else to note is that there is currently no way to remove scopes that have been approved by a user, either programmatically or via the API Keys dashboard. The only method is to create a new app, and make sure the scope is set correctly the first time a user auths.
<opinions>
I’m not a fan of the scope being additive, it should override. If a user is accepting new permissions, those are the only permissions you should have access to.
Secondly there should be a way to wipe scope from an existing app without having to create a new one </opinions>
Thanks again to Noertap for the support on testing this <3
Thanks for working with me on this so quickly @aarongeorge
I agree that the append behavior can be confusing. I’ve updated our documentation to call out the append behavior while mentioning that it might change in the future.
I’ll pass of the feedback regarding this behavior to the team to be considered for future improvements.