OAuth login button to setup Twitter and Salesforce connections.

[chirino]

Instead of having to manually configure the oauth client id/secret and access tokens in the connection configuration screens for Twitter and Salesforce connections, the UI should instead show a 'Login in to ${system}' type button (which should be rendered according to the guidelines of the system being logged into).

This button should do an oauth flow using the client id/secret collected as part of system config as described in #546 and additional config in the connector metadata (info like scopes etc). The resulting oauth access token should then be stored in the connection being created.

[chirino]

There's lots of issues we can run into with this issue:

1. We want some generic way of doing oauth against different systems, but different systems all do oauth slightly differently. We need to figure out a way to abstract those differences.
2. Will the UI loose it's current configuration state if the oauth redirects are going on? Should we do the oauth flows in a popup window?

[jimmidyson]

Yeah we'll need server side plugins for 1.

For 2 oauth requests can include a state parameter which is sent back from provider on success so we can provide UI state that way perhaps. Let's try to minimise popups unless really necessary.

[gashcrumb]

Question though, is that access token a system config thing or tied to a connection? If the latter I don't see how #546 makes sense for this, I'd think the oauth settings would just be part of the connection details screen that we already have.

If it's a system config thing, then how is this access token related to a connection at runtime?

[jimmidyson]

Yeah it's connection info, different connections with the same connector could have different connection info.

[chirino]

So access token is a connection level setting. But the client id and secrets are system level things.

[gashcrumb]

Theoretically though you could use multiple client IDs and secrets for different connections though, couldn't you?

[gashcrumb]

I guess even in that case we can always leave them to be overridden when the connection is created.

As far as configuring this stuff at the system level, I could envision a fairly generic interface to build up the credentials for oauth endpoints where you'd kinda have to know the field names that need to be set, then we can associate those settings via the connector label perhaps...

[zregvart]

Yes you could use multiple Client ID and Secret but that would make this more complicated for some (most?) systems, for example the Client ID and Secret with Salesforce would mean deploying to Salesforce (a definition of connected application). A fixed Client ID and Secret would give an Syndesis host opportunity to gain notoriety, in Salesforce, you can package a connected application in an package that can be deployed to the Salesforce Appstore (AppExchange), and would be presented with branding and copy text that the host chooses. I think that multiple Client ID and Secrets for the same Syndesis host would result in multiple listings in most systems so this is something that the host would not want.

[chirino]

@gashcrumb your right: if we have a connector editor, then yes, an administrator could configure the client id/secret directly on the connector since connectors are system level things. But I don't think we would allow those settings to be changed at the connection level. They should be hidden at that point.

[rhuss]

Is this issue still current ?

[jimmidyson]

Yes this is all part of the OAuth connection flow.

[zregvart]

This has been refined on the backend and should make its way onto staging. Linking to the design proposal and open issues to be aware of.

See syndesisio/syndesis-openshift-templates#63, syndesisio/syndesis-rest#464, syndesisio/syndesis-rest#460

[gashcrumb]

@zregvart awesome timing, will start looking at this today...

[gashcrumb]

@zregvart apologies if I missed it in the proposal, how do I know which fields shouldn't be displayed on the configuration page for the connection? This would be page 2 of the create connection flow.

[zregvart]

@gashcrumb this is what I think: the flow at that page diverges, you either go the credentials route if it supported (/api/{version}/connectors/{connector}/credentials returns a value) and offer only one button Connect with ...` or you use the same screen as now. Does that make sense?

[gashcrumb]

@zregvart ah, of course.

I wasn't sure if there'd be cases where there could be config beyond authentication, but for starters we can restrict this page to just the button.

[gashcrumb]

@zregvart on the POST I notice the URL expects the connection ID. Should this not be the connector ID?

In the typical flow of pages of the create connection flow, the connection itself hasn't been created on the server yet, that's triggered on the 3rd page of the wizard. The only way I could see this working is if I could post a basically an empty connection object with just the connectorId and no name. Or we require the name before configuring the connection, so then we could actually save it first, then configure OAuth.

Sorry I hadn't spotted this earlier, like during the design phase :-/

[gashcrumb]

Design is here, linking from this issue for now so I don't have to go through all the issues and hunt it down again :-)

[kahboom]

Wonder if the designs should be thrown in the epics or the proposals for easy access.

[rhuss]

actually I would love to see the epics as the single entry point, so I'd suggest to link the design to the epics.

This does not mean that we can't add 'comment links' (those via URL) also from design to proposal.

[gashcrumb]

Yeah, to be honest I just stuck the link there because there's a lot of issues across a bunch of repos for this and it took me awhile to find them, once that PR is merged I'll probably add another link to this issue.

[zregvart]

@gashcrumb connection is needed as the OAuth response (i.e. tokens) get applied to the connection, so the backend needs to know what connection it applies that to.

I see two options:

• less correct one: create a empty connection beforehand and keep the flow as is
• more correct one: hold the OAuth tokens in client side state cookie and apply the OAuth tokens at the end of the flow when the connection is created

Obviously one would strive to get the second option done, I'll take a look, should not be much work.

See syndesisio/syndesis-rest/issues/477

[sjcox-rh]

@gashcrumb, sorry If I uploaded the design to the wrong issue. I thought it was the epic but I have a feeling it wasn't, haha.

…

On Tue, Aug 1, 2017 at 5:27 AM, Zoran Regvart ***@***.***> wrote: @gashcrumb <https://github.com/gashcrumb> connection is needed as the OAuth response (i.e. tokens) get applied to the connection, so the backend needs to know what connection it applies that to. I see two options: - less correct one: create a *empty* connection beforehand and keep the flow as is - more correct one: hold the OAuth tokens in client side state cookie and apply the OAuth tokens at the end of the flow when the connection is created Obviously one would strive to get the second option done, I'll take a look, should not be much work. See syndesisio/syndesis-rest#477 <syndesisio/syndesis-rest#477> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#556 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APgSBEFpTRbenS3j2jljAd3MrdFM-29_ks5sTu-MgaJpZM4NiYio> .

-- *Sarah Jane Cox* User Interaction Designer User Experience Design Team Red Hat, Inc. <http://www.redhat.com/about/whoisredhat/redhatstories.html?intcmp=70160000000TB9vAAG&>

[zregvart]

@gashcrumb can we close this, we're tracking remaining issues via epics syndesisio/syndesis-project#30 and syndesisio/syndesis-project#29