Cartodb: [OAuth] Check the flow is kept after signup

Created on 1 Oct 2019  Â·  15Comments  Â·  Source: CartoDB/cartodb

Context

We're implementing an OAuth flow from an external, 100% client-side, web app. It would be common for the potential client not to have a CARTO account, so the first step would be, before authorizing the scopes, creating a new (trial) account.

What we're aiming for is keeping the flow for this "first use-case of creating the account", when this action is triggered from the client application.

We have no 100% evidence, but we suspect that after the Signup every user might be redirected to the Dashboard.

Let's check it here!

Steps to Reproduce

  1. Asking for OAuth permissions from an external web app
  2. Instead of Log in (with an existing account), follow the full Signup process

Current Result

TBD (confirm the result here, please @alejandraarri)

Expected result

Last step after signup is the same as after Login --> user is asked for permissions to whatever scope the final app requires.

Additional info

https://github.com/CartoDB/toolkit and specially the oauth package would be really nice for the tests, as it encapsulates the whole oauth flow from a web app perspective

Ping @rjimenezda if you need some help setting the local web app for the tests

Backend Frontend oauth

Most helpful comment

All 15 comments

Thx a lot @gonzaloriestra. We'll check it out.

The main problem is that oAuth parameters must be passed through the whole signup process and this is not developed.
oAuth 2

First, when the oAuth modal opens there is no way to go to the Sign Up page because there isn’t a link in the mobile size design. Right now, we can access by resizing the window so that the desktop design appears and so, Sign Up link appears too. The issue is that it is a simple link and the oAuth parameters such as client_id,redirect_uri, etc. (or the full oAuth flow URL as a parameter) are not being passed.

In order to fix this, the following should be implemented:

  1. Add a Sign Up link from the “New Session” page
  2. Pass the oAuth parameters from Log In to Sign Up
  3. Keep these parameters through the steps of Signup and Confirmation

Since these pages are rendered by Rails, the flow will have to be modified to add these params so I understand that we will have to involve Backend in this development.

  1. In the Confirmation page a cdb.session.Creation is created that can have a redirect_to. I understand that if it has a value, the final step redirects you to that page instead of to the dashboard.

I think this development involves Design, Backend and Frontend teams and we need to discuss the best solution for this case.

@alejandraarri just as a small note, we will also need a param sent from the client in the SignUp page to present a 'custom UI' if that's the case (same flow, but with some different UI elements). If that is not present, we would present the default current UI for the signup

I think that last part could be done with the current referrer header as the URL login in OAuth is not /login, and it would include all the URL parameters like client_id, and so on. But honestly, I think no one does custom UI for login even if it comes from OAuth as it is a regular login.

It looks like @alejandraarri and @gonzaloriestra have found one part of the problem and are working to fix it. Another part requires more FrontEnd work

The change that @alejandraarri and @gonzaloriestra did is to keep the redirection URL to redirect when server creation is ready but there's one more thing to do.

We need to pass an after parameter to the signup link within the login template, but only if it comes from OAuth authorization flow.

So the thing is, we (@alejandraarri and I) have been taking a look at it and we haven't been able to do it. The aforementioned link is in here and we should pass our redirect_url as an after parameter to signup_url function invocation.

We haven't been able to find the controller which renders the login page, because even though it does some redirects, the URL stays the same. And thus, we don't know where to check whether the rendered login is coming from an OAuth or not.

As it is more of a backend thing, could you please @gonzaloriestra take a look at it?

Hi @gonzaloriestra could you find some time to have a look at it?
It will be nice to know how much effort we need to fix this problem. Thx a lot!

Sorry, I've been quite busy last week.

To clarify a bit the mess of redirections, these are the steps (when Central is enabled):

  • Central: /oauth2/authorize
  • Cartodb: /oauth2/authorize
  • Cartodb: /login
  • Central: /login

If I'm not wrong, what we need is to know in that last controller if it comes from Oauth in order to add the after parameter to the Sign up link.

The only solution it comes to mind would be to pass the after parameter in each one of those redirections. I think it shouldn't be difficult, although all this logic is a bit cumbersome...

Ok, so it seems like it is a backend business as there has to be some after parameter passing through all backend redirections (because they don't appear as redirections in the browser).

I'm gonna unassign us and move it to the backend column, ok?. There's an ongoing PR in central to continue working on that 15122-oauth-signup branch.

It would be nice to ensure in the acceptance if these other related bugs are fixed or not:

Hi @esloho ! Could you please give us a bit of status update when you have time?

Hi @esloho ! Could you please give us a bit of status update when you have time?

Last day we decided to divide the issue in two (see https://github.com/CartoDB/cartodb-central/pull/2588#issuecomment-548314108) so I started the changes though I couldn't make any progress yesterday and I'm not expecting much today since we're in Seville.

Thx a lot for the effort!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

noguerol picture noguerol  Â·  5Comments

arianaescobar picture arianaescobar  Â·  4Comments

ivanmalagon picture ivanmalagon  Â·  3Comments

saleiva picture saleiva  Â·  4Comments

javitonino picture javitonino  Â·  5Comments