Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source SurveyMonkey: support oauth #6283

Closed
sherifnada opened this issue Sep 19, 2021 · 2 comments · Fixed by #7433
Closed

Source SurveyMonkey: support oauth #6283

sherifnada opened this issue Sep 19, 2021 · 2 comments · Fixed by #7433

Comments

@sherifnada
Copy link
Contributor

sherifnada commented Sep 19, 2021

Tell us about the problem you're trying to solve

With the release of Airbyte Cloud, we need to start supporting Oauth for this connector, since it's the recommended way of authenticating users into a SaaS application.

If this connector doesn't support oauth already (i.e: doesn't accept a client_id and client_secret) then we need to update its spec to accept those parameters. I suggest that this be a oneof nested inside a top-level field called "credentials":

{ credentials: { type: object oneOf: [ // api key, // oauth ] } }

See the connector spec reference in the docs for reference on how a oneof can be implemented.

This should be done in a backwards compatible manner i.e: users currently supplying authentication info in the config's top-level should not be impacted by this change.

Acceptance Criteria

  1. The connector supports oauth webflow authentication with client_id/client_secret
  2. Oauth properties are annotated properly. See this PR for an example
@sherifnada
Copy link
Contributor Author

hey @VasylLazebnyk, there’s a follow up that we need to do to the survey monkey oauth PR according to this comment: #7433 (comment)

if the connector always accepts an access token, then there shouldn’t be two authentication mechanisms. The spec should look like the FB Marketing Spec, accepting only an access token, and assumes the connector is always doing oauth. Currently it doesn't make sense that we expose two auth mechanisms, because there is always only one: access key.

@avida
Copy link
Contributor

avida commented Nov 2, 2021

Addressed in #7524 PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants