Hello,
I’m stuck in a situation where I can not verify my Patreon patrons in any way.
I am developing a Flutter mobile app where the premium section is for patrons only.
Yes, Patreon offers OAuth, but it does not work for me for a variety of reasons, some of them outside of Patreon.
If Patreon allowed custom URL schemes in the redirect URI, it would solve my problem, but they are unwilling to do so.
Sadly, Patreon offers OAuth as the ONLY way to get user info, and that’s the problem.
Why don’t they provide alternate APIs, for example: “give a list of patrons based on my API key”
without having to go through OAuth?
The security, based on Client Secret (API key) would remain the same.
Patreon competitor offers that, but I’d prefer to stick with Patreon due to its better market recognition.
At this point, I am clutching at straws, like “embed a password in a monthly post that my patrons have to read in order to log in to my app”
What should I do…?
The redirect uri shouldnt be a problem. You can create an intermediary app somewhere and have it link both Patreon and Flutter. Or even just translate the url that your app receives and change it to Flutter format and send your user to Flutter with that url in the end.
I recommend the intermediary app route - you can have your own local app with its db that easily processes the membership info in however way you want, and it could link to both Flutter and any future app/site that you expand to…
Hello codebard,
Thank you for your reply. I am quite new to OAuth and not sure if I understand this well.
Here is what I understand happens in OAuth:
-
My mobile app requests the initial Patreon OAuth URL www.patreon.com/oauth2/authorize.
-
The web browser window opens and the user logs in with Patreon, [Google, Facebook, etc].
- After user clicks “Submit”, the Patreon code is hit again. Then Patreon requests the redirect_url, which is supposed to be intercepted by my app.
How / where the new, “intermediary app” comes into play.?
At the end of this cycle, I need the code in my primary mobile app to receive the redirect_url, along with the params Patreon adds.
As I said, I can make it work with custom URI schemes, ex… myapp://someurl/…
However, with the Patreon-mandated http or https, the Android OS redirects the redirect Url to the browser instead of my app, and I can’t change this behavior due to some reasons not related to Patreon.
I would appreciate any hints!
The intermediary app can be anything that has a publicly accessible web address/url. It receives the redirect, gets the authorization code from the request and then uses it to get the access tokens.
At the end of this cycle, I need the code in my primary mobile app to receive the redirect_url, along with the params Patreon adds.
Ok, then you dont need an intermediary app since the mobile app fulfills that role. Just redirect the user to the mobile platform’s localhost url equivalent, and then get the code there.
@codebard thanks for your explain.
So what you mean is, it’s required to have intermediate app (probably website will be best solution) and get token from that website redirect uri. And redirect users to mobile app with deep link again by adding some specific tokens, then mobile app can get user info and verify it’s Patreon info, right? It’s too long way to go around, but at least, if we can support mobile auth with this way, then i am willing to test it from my side at first
I will keep posting about the results.
That kind of setup would work with any other app, including desktop software, yeah. But as I mentioned in that other post, I believe there should be something that could be used as the localhost-equivalent for a given mobile platform, but you would need to check and confirm that.
Since I managed to get the OUth working on my mobile Flutter app, I will chime-in on this.
BTW, Flutter is Google SDK that allows writing single codebase that will run on Android, iOS, Web, Linux and Windows
(with just some config tweaks for each platform).
The problem I was facing was capturing within the individual mobile app the Patreon invocation of my redirect URL.
I could not make it happen for the following reason:
- I could capture url with a custom scheme (like myscheme://localhost) but Patreon allows only http/https schemes.
- To capture http/https urls, you need your domain/website.
Then Google/Apple checks a special config file within that
website to determine if you are indeed allowed to redirect that domain URL to your mobile app.
The special config file must be inside a directory named “.well_known”.
Well, too bad my website host does not allow directories to start with “.”.
So, capturing the redirect URL within my app was out.
Here is what I finally came up with.
I use Firebase as Cloud services provider. Firebase has something called “functions”, which is basically a
cloud code that runs when something happens. That something can be a database trigger or URL invocation.
My Firebase function acts as my redirect URL “Website”. It collects the temp token Patreon sends, and then, using Firebase messaging, calls back my mobile app. My mobile app collects the token, and makes subsequent invocations to Patreon APIs.
It still does not work 100%. My cloud function internally calls my app to pass the token, but then it needs to redirect the Patron somewhere. My website has a special page called “Login_confirmation” where I inform the Patron he/she is logged in,
and ask them to go back to the mobile app using the back button.
I would much prefer that the browser is closed
programmatically, but that seems next to impossible due to Javascript security restrictions (but that’s a subject for another discussion)
Well. That setup looks pretty complicated even to start with. Its possible that in the long run you would run into other issues. It would be better to go the intermediary app approach since it would allow you to get around any issue and implement any platform.
Yes, that setup is indeed complicated, but pretty much the only thing I can do considering both Patreon and my website host restrictions.
As far as the “intermediary app approach” - my cloud Firebase function is that intermediary app.
Assume that you have some other website/app that acts as the intermediary.
Do you know what would be the biggest problem?
The biggest problem would be that app/website communicating back to the originating mobile device after receiving Patreon redirect url. it might be possible, but difficult and unreliable.
Firebase cloud messaging solves this problem with a few lines of code.
By allowing only http/s in redirect URL, Patreon largely created this problem, so allowing custom schemes would solve it.
I would also add: is everybody using Patreon APIs in WordPress, and Piao-Riguo and I are the only people struggling to use Oauth APIs in a mobile app?
Well, the future (and the present) are mobile.
No, there is a very wide array of applications that an immense variety of creators and partners use with the api. There was a mobile developer before asking about the same thing, but he soon found out what url to use as localhost replacement in his mobile stack. Your issues seem to be a combination of general cloud application complexity and your mobile stack’s peculiarities.