Open spprichard opened 5 years ago
Is a token permanent?
I'm not sure I get it:
Is that correct?
I have to look at the docs. From what I know usually you get a access token with a time to live. You also get a refresher token. When the access token expires you use the refresher token as a one time use to get a new access token. This is only for tokens with a time to live.
I need to look at the docs to find out for sure.
One of the 2 OAuth flows supports he refresher token like I described
That's what I though!
So how do we handle the tokens?
Is the mobile app going to constantly keep its token up to date by firing queries to the Meetup API?
That how I initially though we would do it:
Can you change this rough diagram to show the system with OAuth?
Another architecture that could potentially make the whole development on Viper end much easier:
With this system, Viper only needs to handle a simple database with a meetup table essentially containing its Meetup's ID, and then other tables handling all our custom data (commenting, scheduling, etc...)
I've added support for OAuth2,
Developers will have to go to https://secure.meetup.com/meetup_api/oauth_consumers/ and create a new consumer account with the same information as provided in the OAuthConstants.swift
file.
@spprichard did you look at those diagram? Are you sure otherwise that sharing token is the way to go? You can grab your token once logged in by console logging UserDefaults.standard.string(forKey: OAuthConstants.meetupAccessToken)
So here is how I see it
How to determine if User is Authenticated? Is this the first time the User has logged into our App? We could determine this by keeping a token in the iOS App, this token is generated on the Server side. The Server (Vapor Backend) is responsible for issuing that token once the User has authendicated with the Meetup Api Via thier OAuth Flow (We would use the Authentication Code Grant Flow).
In my head, All but 1 thing should be handled by the Backend. That one thing is the initial OAuth sign in via the Meetup Api. So the Flow looks something like this
Initial install of iOS app, first launch, check for this special token. It should not be present, that means we should render the Meetup OAuth Page in the Webview within the iOS App. User will enter their creds (we don't store that). That request gets send to the Meetup API (this is where the one time the iOS App will have to talk to Meetup.com).
Upon Successful request to be authenticated with the Meetup.com OAuth flow, the User will be redirected, this request should contain things like the access token, and the refresher token. The access token and the refresher token are we need to be stored in the Backend.
2a. if the Auth fails with Meetup.com (use case: entered wrong creds) the User should be prompted to reenter (basically try again).
We can now start the sync of all the information we need, and the User of the iOS App can continue to use it as they would expect. We may want to show them a loading screen until we have loaded all the information about them into our DB.
This is just what I have in my head. I may be off in some places. This should become more clear once we get something working. @SebastienFCT does this make sense?
Hey Everyone,
So looking into interfacing with the Meetup-API, I've learned a few things.
I propose we change the iOS login screen to be Meetup's Oauth Screen (rendered in a webview), for first time Users when they login. We will then need to provide a way for the iOS app to communicate with the Meetup-API via the OAuth 2 flow. Once that is complete, the iOS App shoiuld "register" this User with the Backend. What it means to register is to give the Backend the token the iOS App got from communicating with Meetup's Oauth 2 flow.
So the requirements