I’m trying to make a request for an OAuth token according to the docs here: https://docs.patreon.com/#oauth
But I’m getting a 403 with a CAPTCHA. Since this is an API, I wouldn’t expect to get a CAPTCHA even if there’s an error. But maybe I’m doing something wrong. I’m making a GET request to http://www.patreon.com/oauth2/authorize?response_type=code&client_id=<my_id>&redirect_uri=<my_uri>. I’ve checked that the client_id and redirect_uri are correct. This is what I’m seeing:
I saw on this post that a User-Agent header is also required. That’s not mentioned in the docs, but I tried adding User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0 too, and I still get the same result.
Are you now able to connect to the api without captcha?
No, I just tried again right now and I’m still getting a CAPTCHA. I’m fairly certain that my HTTP request is correct, but because I’ve gotten mixed information about what the request should look like, maybe you could share a curl request with me that works, and then I can try it.
PHP lib’s examples have various examples ranging from getting user info to webhooks. The readme also has a login example. You can try confirming whether any of those calls work in your own app when constructed.
I’m sorry, I don’t understand. I’m telling you that I’m making a request exactly like what is in the readme and that I’m getting a CAPTCHA, so something about the readme seems to be wrong, or I’m misreading it. How is reverse-engineering the same request from the PHP lib’s example going to help me make the request? I’m trying to make this request in a REST client to confirm that it’s working (it’s not), and then when I have a working request I’m trying to get it to work in as a Custom Social Extension in Auth0, which uses JavaScript. I tried to get it working in Auth0 already, but I get an error that just says “invalid_connection”, which is why I’m trying it in a REST client.
It looks like someone else had a similar problem with no resolution.
Anyway, to restate the problem in different terms, when I try to make the following curl request to the documented oauth authorization endpoint:
curl --request GET \
--url 'https://www.patreon.com/oauth2/authorize?response_type=code&client_id=my-client-id&redirect_uri=https%3A%2F%2Fmywebsite.com' \
--header 'content-type: application/json' \
--header 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36'
It doesn’t work, and I get the following response in the terminal:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to target URL: <a href="/login?ru=%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26cl
ient_id...">/login?ru=%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id...</a>. If not click the link.
Maybe this is an issue with CloudFlare? If the API is behind CloudFlare maybe there is something about this request that’s being flagged as suspicious? I tried with a VPN and without, I tried with the client_secret and without, I tried various User-Agent strings, I’ve tried every combination I can think of. Can you please take a look at this curl request and tell me if you see anything wrong there? If not, maybe the issue is with CloudFlare?
I recommend first, trying DMing Jackie (in belo message) your IP so she can track your request across cloudflare.
If that fails, here is a potentially fruitful debug route:
Modify the PHP lib to return all headers after a call instead of only returning the body (in api class and oauth class)
Set the PHP lib in a VPS or dedicated server that faces the internet.
Using exact app info (access tokens, everything) , replicate the exact call using PHP lib by using its relevant example.
Record the return headers, everything from uuid to whatever is returned, and send them to me via dm in the forum here.
This will allow that exact request to be tracked across services and can provide the reason for the call failing.
Hey @localjo - this definitely sounds like Cloudflare is picking up your request as suspicious, and serving a captcha. If I can collect some more info on where you’re connecting from, I can track this down better. Can you DM me with the IP you’re connecting with?
Best,
Jackie
Hi @Jackie_Bow I’m traveling in Las Palmas, Spain. Unfortunately, I don’t have a static IP address right now. But my end goal here is not to get the request working on my machine (that’s just so I can debug the problem). My end goal is to set up an OAuth connection between Patreon and Auth0, but I was having trouble getting it to work.
I figured it out today, and it looks like there were a few problems. Posting my solution here in case anyone else needs it.
I had to fill out Auth0’s Custom Social Connection form like this:
The first thing I was missing were the Custom Headers, since that isn’t mentioned in the Patreon documentation. This is the value I used;
{
"Content-Type" : "application/x-www-form-urlencoded",
"User-Agent" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
}
When I did that, I started getting the following error;
{"error":"invalid_request","error_description":"Mismatching redirect URI.","state":"xxxxxx"}
So I realized that in order to get a Patreon client to authenticate correctly with Auth0, I need to add Auth0’s redirect URL to my Patreon client: https://{my-auth0-subdomain}.auth0.com/login/callback
This gets me to the Patreon confirmation dialog, and redirects back to Auth0, but then I see the following error in Auth0, so it looks like something is still wrong;
{
"statusCode": 403,
"data": "{\"error\":\"invalid_grant\",\"error_description\":\"Invalid authorization code\"}"
}
I can’t inspect the request that Auth0 makes to the Patreon Token URL, so I’ve opened an issue to their support to see if they have any suggestions.
It looks like this is either an issue of the request to the Token URL that Auth0 makes being malformed, or the Patreon OAuth API passing invalid/expired codes or not accepting valid codes. Any suggestions on how to further debug this would be very much appreciated.
Thank you for the detailed response, @localjo! And apologies for the continued issues - I can see how frustrating that is. Let me pass this along to our team focused on OAuth and see what we can do.
Best,
Jackie