Notion Auth API doesn't support scheme, it only supports https:// as redirect url
In my Flutter (Android) app I am using Flutter Custom tabs and Firebase Dynamic Links for notion OAuth2 apis.
My dynamic link is https://myappname.page.link/start
The deep link is https://myappname.page.link
Notion is using the https://myappname.page.link/start as a redirect_url , and is supposed to append some parameters to it, so it looks like https://myappname.net?code=xxx
However, all I receive inside my app is the naked url https://myappname.page.link
There are no parameters attached to it.
After researching for more than 2 hours, I know I can't customise this using Firebase Dynamic Links.
Is there a better way to listen for incoming response inside of a Flutter app, without the use of Dynamic Links?
You can try to use state param and pass there whatever you want. It's a part of the OAuth, so notion auth API should add the param to your redirect url.
https://developers.notion.com/docs/authorization
Related
I'm a beginner developer. I am writing an iOS application using Flutter. I need to use an API to identify my user. The provider of that API asks me to send them a redirect URL. From what I understand, when an user identify themselves on my app, a request will be send to the API provider, and once the user is correctly identified, the API provider want to know where to send the user (the redirect URL). But I want the user to stay on my app.
How should I set up that ?
Thanks
The usual way to implement this is via the AppAuth pattern, where the app invokes an ASWebAuthenticationSession window, which is a secure browser. From a UX viewpoint it looks integrated and remains a part of the app.
As a next step, maybe have a look at my iOS AppAuth Basic Tutorial to see what this looks like. The simplest option is a private URI scheme based redirect URL that looks like this:
net.openid.appauthdemo:/oauth2redirect
Once the concepts are understood, and your team has reviewed the user experience etc, the next step would be to implement this behaviour in Flutter.
I am trying to build a login screen for Flutter right now. I have two questions related to how it works in Flutter.
I have my backend set with React and use cookies for auth check. Is it possible to store cookies like web in Flutter? I have cookie validation backend that it checks for valid cookies. Wondering if I can still use this in Flutter.
If I use a local storage approach, do I have to setup a permission request for that? And, if a user rejects then I can't use it correct? Moreover, does android users have access to this file?
I am not using Firebase, I have my own backend. Is there a best practice for Node <---> Flutter auth? Most questions or doc are related to Firebase.
There is no support for something like Android AccountManager yet, but there are some plugins that do similar things:
https://pub.dev/packages/accountmanager
https://pub.dev/packages/account_manager_plugin
/EDIT:
There is a CookieStore class if you want to store cookie
https://api.flutter.dev/flutter/dart-html/CookieStore-class.html
Is there a way to redirect a form POST to a specific page if the endpoint return a success ?
In my specific case, I'm using django-rest-auth to manage the users authentication, and the login endpoint (/rest-auth/login/) return a JSON with the response. I want to redirect the user to his dashboard if the authentication is successfull.
EDIT : As far as I understand, the REST api is only for backend. If I want to set a redirection after any form post, I have to find a way only with my frontend application. Am I right ?
In this case, is Django a good choice to develop the frontend application ?
I've seen many subjects where AngularJS is mentionned to build the frontend. Is it a good idea to build a client app with JS (I mean, for a one page web api, there is no back and next navigation possibility, I think this is not a friendly way to navigate) ?
If I build my frontend with Django, do I have to write my own view, call the backend rest endpoint in this view, process the result, and send an HTTPRequest (for exemple) from this view ? I don't really understand where is the gain with this method.
Well, answer to your question couldn't be only one solution.
You have two ways:
use full RESTful app, using Django Rest Framework and Single
page application
create your own auth views, where you decide
where to go after logging in
Everything depends on your needs.
If I want to set a redirection after any form post, I have to find a way only with my frontend application. Am I right ?
Yes, you need to do the redirection on the front-end.
In this case, is Django a good choice to develop the frontend application ?
Django is a framework for building web servers, and it has nothing to do with front-end.
I mean, for a one page web api, there is no back and next navigation possibility, I think this is not a friendly way to navigate)
There is. For example, here is the ui-router for angularjs. Here is an example of an actual working page. As you can see, the url changes accordingly, just behaves like traditional server-rendered static html pages.
When the browser sends a request to your server, django calls the corresponding view function to render a view, which is just an html file, and sends it back to the browser. Then the browser renders the page. Beyond this point, django has nothing to do with the html file anymore. It is the browser's job to parse the html, and render it accordingly.
So, to be clear, django is not for front-end. For your web application, you can use angularjs for sure. However, if you don't really want to write a lot of javascript code, I suggest taking a look at Polymer (polymer-project.org, oh my little reputation), which is really easy to use.
I need to have two different Facebook connection on the same website! So, they points to two different Application Keys.
How can I manage this?
This isn't something Facebook JavaScript SDK supports and this can't be simply achieved by storing FB object in other variable before adding another instance of SDK.
In the code of SDK FB is used directly pretty everywhere, and the response from API will use it too.
BTW, Even if it was possible your users would be needed to Authorize two applications if you want to access their data (transfer of data from one application to another violate platform policies).
As #JuicyScripter wrote, the js sdk itself can not be shared among different apps in the same document, and that's exactly what you can try to play with.
How about adding an iframe per fb app?
You have the main page (the +1) which acts as usual, then you load an iframe inside of it and in it you can load another fb sdk for a different application.
Depending on what exactly you plan on doing, you might need to communicate between iframes, which will only work if they share the same domain.
Another approach is to make all api requests from the server side, but you'll have to have an access token for the user per app.
I'm working on an iPhone app that ideally uses OAuth to communicate with Twitter. I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The problem is, Twitter has this whole scheme for working with desktop apps, using a pin number. When I register my app with Twitter, they have a web form asking me if I'm a desktop or web client. If I choose desktop client, when I try to have the user authorize, I can set the oauth_callback parameter but Twitter will ignore it after authorization and show a pin number. If, on twitter's form, I specify that I'm a web client, it requires me to enter a URL to redirect to after authorization. And, since I'm using an iPhone app-specific url scheme, their web form fails on validation as it only seems to accepts URLs conforming to the HTTP protocol.
So, it seems like I'm stuck - I can't say "desktop" because I don't want to bother with a pin, and I can't say "web" or I can't use an iPhone app URL. Any solution to this?
From your question:
I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The Pownce article suggests that quitting your application and opening Mobile Safari to perform the authentication step is problematic, and that they started receiving bad reviews from users for doing it that way. They also experienced a failure rate of around 40%.
Pownce's solution is to use a UIWebView within your application instead, so I have a feeling you may have misinterpreted their recommendations. That being said, they do label this as a "naive" solution and go on to suggest a bunch of theoretical "ideal" solutions.
Another point you might not realise is that desktop applications (using the "out of band" / pin number method) and web applications need to open the Twitter site in either an embedded or external browser.
So you've got two choices on the iPhone:
Open up twitter.com in a UIWebView, specifying no oauth_callback parameter or oauth_callback=oob to start the pin-based out-of-band flow. The user then needs to copy the pin using the iPhone's copy-paste functionality, manually close the UIWebView, and paste the pin into your application. The pin can then be used converted to an access token.
Do it how everyone else is doing it (UIWebView + custom-uri://foo.bar in the callback parameter).
For obvious reasons, the first option is pretty crap and really only useful on platforms where Twitter is unable to redirect to a custom URI.
A simple solution may be to create an HTTP page that always sends a 301 redirect to your custom URL scheme and then provide that HTTP URL to the twitter web API.
Aside from that, Nathan's answer is very complete.
Here's how I do it: tell Twitter you're a web app, and make up any old HTTP:// URL to satisfy Twitter during registration of your oauth client.
Then in your app, pass the URL you want to in the callback parameter. Twitter (in my experience) uses the one you give it.
You could use an intermediate website for the authentication. Your app creates a unique id (hardware based?) and stores it. It then records it has sent the user for authentication and sends the unique id to your website. It then redirects the user to your website. Your website then sends the user to Twitter using oAuth. The user returns to your website and you mark the unique id as authenticated and store the authentication information. The user restarts the app on the iPhone, it reads it has sent the user for authentication and contacts your website with the unique id - and reads in the authentication information.
Long winded and needs another website, but it should work.