Skip to main content

OAuthInternetAccount

Auto-generated @jbrowse/mobx-state-tree API for the current JBrowse release — see pluggable elements for concepts. Provided by the authentication plugin. View source.

The configuration slots for this model are documented on its config schema page.

Properties

MemberDescription
type
type: types.literal('OAuthInternetAccount')
configuration
configuration: ConfigurationReference(configSchema)

Getters

MemberDescription
conf
ModelInstanceTypeProps<Record<…>> & { setSubschema(slotName: string, data: Record<string, unknown>): any; setSlot(slotName: string, value: unknown): void; } & IStateTreeNode<...>
The config typed off the concrete schema. ConfigurationReference erases self.configuration to any (the reference's MST instance brand doesn't carry the schema's slot definitions), so reads go through this getter to recover per-slot types and slot-name validation.
authEndpoint
string
tokenEndpoint
string
needsPKCE
boolean
clientId
string
scopes
string
state
string		OAuth state parameter: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1

Can override or extend if dynamic state is needed.
responseType
"code" | "token"
refreshTokenKey
string
authFlowParams
Record<string, string>		Extra parameters to add to the authorization request. Empty here; a provider that needs one of its own overrides this.

Methods

MemberDescription
retrieveRefreshToken
() => string | undefined

Actions

MemberDescription
storeRefreshToken
(refreshToken: string) => void
removeRefreshToken
() => void
postTokenGrant
(grant: Record<string, string>, describeError: (response: Response) => Promise<string>) => Promise<string>
POST a grant to the token endpoint and read the access token out of the answer. Both grants this account makes — trading the authorization code on the way in, trading the refresh token when the access token expires — are the same form-encoded request to the same endpoint answered by the same body, and OAuth 2 says so (RFC 6749 §4.1.3, §6). They differ in the grant's own parameters and in what a failure means, which is what stays at the call sites.
exchangeAuthorizationForAccessToken
(code: string, redirectUri: string, codeVerifier: string | undefined) => Promise<string>
exchangeRefreshForAccessToken
(refreshToken: string) => Promise<string>
validateTokenWithProbe
(token: string, probe: (token: string) => Promise<Response>, describeError: (response: Response, reason?: string | undefined) => Promise<string>) => Promise<...>
Prove a token against the resource and, if that fails, refresh it once and prove the new one. Returns whichever token worked; throws if neither does. Every OAuth account validates this way and they differ only in what a probe is — a HEAD of the resource here, a metadata call for Dropbox and Google Drive.
getTokenViaAuthFlow
() => Promise<string>		Opens the provider's auth page and returns a promise for the resulting token. For Electron, drives the flow directly via IPC; for web, opens a popup and waits for the redirect message.
getTokenFromUser
(resolve: (token: string) => void, reject: (error: Error) => void) => Promise<void>
validateToken
(token: string, location: UriLocation) => Promise<string>