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

Added IntegrationProvider, IntegrationToken tables, GitLab auth, migrated Mattermost to the new data format #5805

Closed
wants to merge 44 commits into from

Conversation

BartoszJarocki
Copy link
Contributor

@BartoszJarocki BartoszJarocki commented Dec 17, 2021

This PR adds two new tables: IntegrationProvider and IntegrationToken, migrates existing Mattermost integration to a new type, and adds a GitLab auth integration. See more information here.

Base PR for reference: #5594
Base RFC: #5567

The main goal of this PR was to remove provider-specific columns from IntegrationProvider and IntegrationToken tables, fix the TS errors, and do some code cleanup.

Leftovers

  • remove authorizeOAuth2 helper method, as we continue to improve our integrations the differences between GitLab/GitHub/Atlassian OAuth2 grow
  • Figure out a better table name for IntegrationToken, maybe UserIntegration?

@jordanh's Loom about new tables: https://www.loom.com/share/22037d51a1404fa5aab5d6ba10c98778

Self-review, my first Loom so I'm sorry for being chaotic! https://www.loom.com/share/9435223bbeeb47da977343d65d6c95bc

jordanh and others added 28 commits November 8, 2021 21:00
- TODO: add userId to MattermostAuth, query best auth for team
Before, when we did an "import someImage 'static/some.png'", file-loader
would give us a path relative to the root like 'dist/[hash].png'. Now,
we'll:

   - Use the CDN if it's configured
   - Serve up the assets via `static/` otherwise

Also:
   - makeMattermostAttachments fixed to server assets from CDN
Also:
   - Fixed bugs in (Add|Update)IntegrationProvier mutations where
     we were returning the wrong error type (and sometimes the
     incorrect error variable!)
   - Added comments and TODOs to enhance AddIntegrationProvider
     when an oauth token is specified to work like AddIntegrationToken and,
   - validate that new tokens are functional by loading the appropriate ServerManager
     and running a method that tests that ServerManager's connection
@jordanh
Copy link
Contributor

jordanh commented Dec 17, 2021

Align client mutations and data types to the new structure (will we ever get GraphQL input union types? 😢)

I felt this too, so hard, when I was coding this set of features

if (queryParams) {
uri = uri.concat(`?${stringify(queryParams)}`)
}
const oauth2Response = await fetch(uri, {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrap in try/catch

additonalHeaders?: Record<string, string>
}

export const authorizeOAuth2 = async ({
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove me

@mattkrick mattkrick changed the base branch from add-gitlab-auth to master December 21, 2021 18:36
@BartoszJarocki BartoszJarocki force-pushed the feat/integration-providers branch from 8e8d5e1 to c0813b7 Compare December 22, 2021 14:22
@BartoszJarocki BartoszJarocki marked this pull request as ready for review December 22, 2021 16:54
@BartoszJarocki BartoszJarocki changed the title Changed integration providers schema [base: add-gitlab-auth] Added IntegrationProvider, IntegrationToken tables, GitLab auth, migrated Mattermost to the new data format Dec 22, 2021
@BartoszJarocki
Copy link
Contributor Author

@Dschoordsch I'd really appreciate it if you could take a look, thank you!

Copy link
Member

@mattkrick mattkrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take a crack at these comments over winter break, i know there are a lot!

@mattkrick mattkrick mentioned this pull request Jan 4, 2022
9 tasks
Copy link
Contributor

@Dschoordsch Dschoordsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this change relates to #5829 so I just have a few comments for now.

packages/client/modules/demo/DemoUser.ts Show resolved Hide resolved
"teamId" VARCHAR(100),
"isActive" BOOLEAN DEFAULT TRUE NOT NULL,
"name" VARCHAR(250) NOT NULL,
"providerMetadata" JSONB NOT NULL DEFAULT '{}',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 why not call it just "metadata"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think that was chosen to differentiate between tokenMetadata & providerMetadata (it gets confusing when you're in the thick of it, especially because the types weren't originally very strict).

IMO i think we should just use columns, then we get types for free!

return null
}

const addIntegrationToken = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 maybe name it addUserIntegration after its purpose

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i agree token referring to an entire DB row feels bad.
technically, it isn't related to the User, but the TeamMember.
maybe IntegrationTeamMemberAuth? IntegrationAuth? IntegrationAuthStrategy?

name
updatedAt
providerMetadata {
... on OAuth2ProviderMetadata {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going forward with this, does that mean if we have a integration provider which supports OAuth2 and PAT we would split it into 2 different providers?

$providerId: ID!
$oauthCodeOrPat: ID!
$teamId: ID!
$redirectUri: URL!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why we can't trust the redirect URI here? If we pass a wrong one, then adding the token will fail. It's not used for anything else. Since the client does the initial redirect itself, it should also know which redirect URI was used. The OAuth provider should also be set up to only allow the correct redirect URIs.

})

const data = {userId: viewerId, teamId}
publish(SubscriptionChannel.TEAM, teamId, 'AddIntegrationToken', data, subOptions)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTIFICATION channel, not team. team doesn't get to know about 1 persons token

@BartoszJarocki
Copy link
Contributor Author

closing in favor of #5829

@mattkrick mattkrick deleted the feat/integration-providers branch June 3, 2022 23:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GitLab auth shipped behind feature flag, Mattermost to new Auth tables
4 participants