Auth Hooks #1993

infomiho · 2024-04-24T16:47:01Z

Adding hooks:

onBeforeSignup
onAfterSignup
onBeforeOAuthRedirect
~~onAfterOAuthTokenReceived~~

Left to do:

Changelog
Docs
Headless tests Adds auth hook headless tests #2022

infomiho · 2024-04-24T16:47:47Z

waspc/examples/todoApp/src/auth/hooks.ts

@@ -0,0 +1,30 @@
+import type {


Example usage of the hooks

infomiho · 2024-04-24T16:48:06Z

waspc/examples/todoApp/main.wasp

@@ -40,7 +40,11 @@ app todoApp {
      },
    },
    onAuthFailedRedirectTo: "/login",
-    onAuthSucceededRedirectTo: "/profile"
+    onAuthSucceededRedirectTo: "/profile",
+    onBeforeSignup: import { onBeforeSignup } from "@src/auth/hooks.js",


Declare the hooks in the auth dict

infomiho · 2024-04-24T16:48:56Z

waspc/data/Generator/templates/server/src/auth/providers/config/github.ts

-                const { accessToken } = await github.validateAuthorizationCode(code);
-                return getGithubProfile(accessToken);
-            },
+            getProviderTokens: ({ code }) => github.validateAuthorizationCode(code),


Refactor OAuth a bit to split getting tokens and getting user profile into two steps so it's easier to write a hook onAfterOAuthTokenReceived

infomiho · 2024-04-24T16:49:27Z

waspc/data/Generator/templates/sdk/wasp/server/auth/hooks.ts

+import type { ProviderId, createUser } from '../../auth/utils.js'
+import { prisma } from '../index.js'
+
+type CommonInput = {


Each hook will receive hookName, prisma and Express's req object.

I suggest changing the name to CommonAuthHookParams.

Also, consider whether this affects how the IDE displays the types and whether it's worth it. The user probably doesn't care what's common and what's not common - they just want to see which params they have.

Renamed the symbol and added the Expand helper so user would see full types

infomiho · 2024-04-24T16:49:54Z

waspc/data/Generator/templates/sdk/wasp/server/auth/hooks.ts

+} & CommonInput
+
+/* On Before OAuth Redirect Hook */
+export type OnBeforeOAuthRedirectHookFn = (


Users have the ability to modify the OAuth redirect URL

infomiho · 2024-04-24T16:52:18Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/user.ts

    const user = await createUser(
      providerId,
      providerData,
      // Using any here because we want to avoid TypeScript errors and
      // rely on Prisma to validate the data.
      userFields as any,
    )
+    if (onAfterSignupHook) {


infomiho · 2024-04-24T16:52:35Z

waspc/data/Generator/templates/server/src/auth/providers/username/signup.ts

@@ -34,13 +35,19 @@ export function getSignupRoute({
    })

    try {
-      await createUser(
+      if (onBeforeSignupHook) {


infomiho · 2024-04-24T16:52:39Z

waspc/data/Generator/templates/server/src/auth/providers/username/signup.ts

        providerId,
        providerData,
        // Using any here because we want to avoid TypeScript errors and
        // rely on Prisma to validate the data.
        userFields as any
      )
+      if (onAfterSignupHook) {


infomiho · 2024-04-24T16:52:50Z

waspc/data/Generator/templates/server/src/auth/providers/email/signup.ts

-            passwordResetSentAt: null,
-        });
+    try {
+      if (onBeforeSignupHook) {


infomiho · 2024-04-24T16:52:54Z

waspc/data/Generator/templates/server/src/auth/providers/email/signup.ts

+        // rely on Prisma to validate the data.
+        userFields as any,
+      )
+      if (onAfterSignupHook) {


infomiho · 2024-05-08T12:10:05Z

waspc/e2e-test/Tests/WaspComplexTest.hs

          "    methods: {",
          "      google: {}",
          "    },",
-          "    onAuthFailedRedirectTo: \"/login\"",
+          "    onAuthFailedRedirectTo: \"/login\",",
+          "    onBeforeSignup: import { onBeforeSignup } from \"@src/auth/hooks.js\",",


I've included hooks in the e2e test

infomiho · 2024-05-08T12:10:23Z

waspc/e2e-test/Tests/WaspComplexTest.hs

      unlines
-        [ "entity SocialLogin {=psl",


I've cleaned up the e2e tests not use old auth concepts 👍

web/docs/auth/auth-hooks.md

infomiho · 2024-05-09T14:08:12Z

@sodic and I jumped on quick call to discuss some of the OAuth hooks since I felt I didn't design them to be that useful.

We concluded the following:

we should remove the onAfterOAuthTokenReceived hook since the developer doesn't have access to user and the accessToken at the same time. This makes the accessToken useless if you want to save it on some user for later use.
- Solution: We'll just forward the accessToken in the onAfterSignup hook. ✅
we should investigate how to have "state" when using the onBeforeOAuthRedirect hook. This is the only OAuth hook where the developer can get some user input from the client. This input gets lost in the follow up hooks e.g. onAfterSignup doesn't have access to it, so it never can be saved on the user entity.
- Idea: It would be ideal to somehow keep track of the user input across the OAuth hooks so the it can be used again in the onAfterSignup hook ✅
- I'll investigate how to best achieve this.

infomiho · 2024-05-23T14:54:30Z

waspc/data/Generator/templates/server/src/auth/providers/config/github.ts

@@ -77,13 +77,11 @@ const _waspConfig: ProviderConfig = {

        return createOAuthProviderRouter({
            provider,
-            stateTypes: ['state'],
+            optionalStateTypes: [],


Since the state is always sent and we rely on that knowledge in the new hooks, I've refactored this a bit to reflect the fact that the state will be always present in the oAuthState object.

infomiho · 2024-05-23T14:55:51Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

-    setOAuthCookieValue(provider, res, 'state', state);
-    result.state = state;
-  }
+  const state = generateState();


Always set the state since it's always used and will always be used for each future OAuth provider.

sodic

Gotta run now, will finish the review tomorrow morning.

Nice work with this!

sodic · 2024-06-03T13:56:17Z

web/docs/auth/auth-hooks.md

+
+For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:
+
+```wasp


You might want to consider adding a TS/JS switch here for consistency. I'm fine either way.

sodic · 2024-06-03T13:58:40Z

web/docs/auth/auth-hooks.md

+import { EmailPill, UsernameAndPasswordPill, GithubPill, GooglePill, KeycloakPill } from "./Pills";
+import ImgWithCaption from '@site/blog/components/ImgWithCaption'
+
+Sometimes you need to do some action _before_ the user signs up or _after_ they sign up. Or you need to access the OAuth redirect URL or the OAuth access token. For these cases, you can use the Auth Hooks.


Examples would help here.

Also, I have a couple of suggestions for the style. Take the ones you want:

some action -> something - "some action" sounds weird to me.

Too many "or"s

For these cases... -> Auth hooks can help you here.

I also suggesting adding a sentence that explains the term "hook" to avoid the "curse of knowledge". For example: ... Auth hooks can help you here. Use them to "hook into" different parts of Wasp's authentication flow

Also, consider using the Oxford comma where appropriate ("Use the oxford comma" from the style guide)

sodic · 2024-06-03T13:59:59Z

web/docs/auth/auth-hooks.md

+
+## Available Hooks
+
+For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:


Suggested change

For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:

You must first declare all desired hooks in your Wasp file:

A little shorter while conveying the same message.

sodic · 2024-06-03T14:02:49Z

web/static/img/auth-hooks/signup_flow_with_hooks.png

I'd drop the 'user' rectangle below "User account is created. It makes the graph look cleaner and I don't think we lose anything.

I've simplified the diagrams and dropped all of the "data" rects.

sodic · 2024-06-03T14:05:37Z

web/static/img/auth-hooks/oauth_flow_with_hooks.png

The "Redirect to Google. Get auth token. User singup data is received" part is little confusing. It's the only text that contains several actions, but there's no delimiter.
Can we separate this into three separate actions, or put some commas in there?

Also, why do we need the rectangle with oauth: token below if we can't use it? Can we drop that?

I've made it into a single action that reads okay.

Also, why do we need the rectangle with oauth: token below if we can't use it? Can we drop that?

I wanted to point out where the data that appears in the hooks comes from. But it was getting crowded so I dropped all the data rects.

sodic · 2024-06-03T16:32:16Z

waspc/data/Generator/templates/server/src/auth/hooks.ts

+type UserHookParamsToInternalHookParams<T> = T extends (
+  params: infer P,
+) => unknown
+  ? Omit<P, 'prisma' | 'hookName'>


There's some duplication here. We should query the names of these fields from CommonInput.

I've changed my mind on what I've written below. While technically still true, the wrapper is too complex to make it worth it. I'm leaving the old text for posterity:

Warning
Outdated opinion
Also, the type is generic (suggesting all three functions/wrappers act in the same way on purpose), while the functions themselves are duplicated (suggesting that there's no knowledge duplication and the structural similarities are a coincidence).

I'm not sure which one it is, but I suggest making it consistent:

If you want to treat the hooks independently, they shouldn't use a generic type

If you want them all to conform to the same interface, make a generic wrapper.

That would work we didn't have a param we want to keep from the CommonInput which is req.

Common input has hookName, prisma and req, we want to keep out the first two. If I used keyof to get the keys of the CommonInput, I'd still need to write down the literal req which would still be duplication.

Did I understand this comment correctly?

sodic · 2024-06-03T16:44:54Z

waspc/data/Generator/templates/server/src/auth/hooks.ts

+  })
+{=/ onBeforeSignupHook.isDefined =}
+{=^ onBeforeSignupHook.isDefined =}
+export const onBeforeSignupHook = undefined


I suggest using null.

As for the bigger picture...

From the generated code's perspective, this is a little weird. We always have a check if(hook) before calling a hook. But that check is (again, from the runtime's perspective) always unnecessary.

Once the code is generated, the hook either null or a function. It feels weird to generate code that will perform this check considering that, at that point, we know already know the check's outcome.

I understand why you did it. You didn't want too much coupling and ugly template logic in the handler file, but I'd argue that delegating already existing knowledge to the runtime instead of acting on it immediately isn't a huge improvement.

So, I propose a third solution. Instead of setting the internal hook functions to null and undefined, set them to a no-op (e.g., () => undefined). For the one that returns a redirect URL, just return the original URL. Then, always call the hooks from the handler.

I've went with no-op and identity functions 👍 Great suggestion which makes the code cleaner.

sodic · 2024-06-03T17:00:17Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/cookies.ts


 export function setOAuthCookieValue(
  provider: ProviderConfig,
  res: ExpressResponse,
-  stateType: StateType,
+  stateType: RequiredStateType | OptionalStateType,


Seems like we could make a type StateType = RequiredStateType | OptionalStateType

I've simplified the logic so this no longer applies.

sodic · 2024-06-03T17:03:37Z

waspc/data/Generator/templates/sdk/wasp/server/auth/hooks.ts

+}
+
+/* On Before Signup Hook */
+export type OnBeforeSignupHookFn = (


Let's add it when it proves necessary.

sodic · 2024-06-03T17:06:36Z

waspc/data/Generator/templates/sdk/wasp/server/auth/hooks.ts

+}
+
+/* On Before Signup Hook */
+export type OnBeforeSignupHookFn = (


I suggest dropping the Fn part, OnBeforeSignupHook should be enough.

I know we have SeverSetupFn and whatnot, but I'm not a fan of those either. I'd change them to SetUpServer or something.

Of course, changing this know makes our public API names inconsistent. If you think keeping the consistency is more important, I'm all for it.

I'd probably sacrifice consistency in this case, but it's your call.

sodic

Ok, finally done with everything 😄

I didn't try the playing around with the feature, I trust it works. Let me know if you still want me to try it out.

All in all, this is looking pretty nicely. I left a lot of comments mostly because of:

The docs.
Refactoring suggestions.
The fact that I'm the only one reviewing this.

Some refactoring comments talk about the previous version of the code. Decide what you want to tackle and what not (I don't think any of them were a big deal).

As for the stuff that must be fixed, it's just one type error (ST instead of OST, you'll know when you find the comment). And please figure out why that's not failing anywhere.

sodic · 2024-06-04T15:25:57Z

waspc/src/Wasp/Generator/ServerGenerator/JsImport.hs

+aliasedExtImportToImportJson ::
+  JsImportAlias ->
+  Path Posix (Rel importLocation) (Dir ServerSrcDir) ->
+  Maybe EI.ExtImport ->
+  Aeson.Value
+aliasedExtImportToImportJson importAlias pathFromImportLocationToSrcDir maybeExtImport = GJI.jsImportToImportJson aliasedJsImport
+  where
+    jsImport = extImportToJsImport pathFromImportLocationToSrcDir <$> maybeExtImport
+    aliasedJsImport = JI.applyJsImportAlias (Just importAlias) <$> jsImport


I got lost with all the import, js import, import json functions and types... but shouldn't this thing exist already?

We are already doing aliased imports for operations, so we should have this. Can you please look into it?

Also, the function's name seems a little off. It suggest it maps an aliased ext import to import json, but it does something different (maybe too many things).

Finally, this file exports some symbols no one else uses, and even has a function or two that aren't used at all. This is not at all related to your PR, but I suggest cleaning it up a little - this JS import stuff has gotten a little out of hand. We should try to tame it.

I got lost with all the import, js import, import json functions and types... but shouldn't this thing exist already?

We are already doing aliased imports for operations, so we should have this. Can you please look into it?

The operations aliasing function is really a special case that imports symbols from the wasp/operations/sdk vs. this function importing from user files. So I couldn't really use it here.

I believe the proper solution is to automate this i.e. #1865

sodic · 2024-06-05T08:03:06Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

-): { [name in ST]: string } {
-  const result = {} as { [name in StateType]: string }
+  res: ExpressResponse
+): { [name in OST]: string } & { [name in RequiredStateType]: string } {


Why not use Records here? Did you want to document the name property?

Also, why use a product type instead of a union in the key type (as you did when asserting result). All in all, this is how I'd write it:

Record<RequiredStateType | OST, string>

sodic · 2024-06-05T08:04:55Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts


-  if (stateTypes.includes('codeVerifier' as ST)) {
+  if (optionalStateTypes.includes('codeVerifier' as ST)) {


This ST here should throw an error somewhere. Can you please check whether wasp start and wasp build let it through?

I've adjusted the code, so this is no longer relevant.

sodic · 2024-06-05T08:21:21Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

+  const result = {} as {
+    [name in OptionalStateType]: string;
+  } & {
+    [name in RequiredStateType]: string;
+  } & {
+    code: string;
+  };


Most of the other two big comments apply to this function as well, I think.

sodic · 2024-06-05T08:56:56Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

+export type RequiredStateType = 'state';

-export function generateAndStoreOAuthState<ST extends StateType>(
-  stateTypes: ST[],
+export type OptionalStateType = 'codeVerifier';


Besides creating a union called State (mentioned in #1993 (comment)), I also recommend specifying more information with these types and colocating all the knowledge we have on them.

For example, the value for both states is of type string, but this knowledge is sprinkled throughout the functions. I recommend we list it explicitly:

export type RequiredOAuthState = { state: string } export type OptionalOAuthState = { codeVerifier: string } export type OAuthState = RequiredOAuthState & Partial<OptionalOAuthState>

And then you have both names and values of states defined in the same place. You can get extract just the names, just the values, or both from this type:

type OptionalOAuthStateType = keyof OptionalOAuthState

The types contain all knowledge and everything else just follows. The types functions use become simpler as well:

function generateCodeVerifier(): OAuthState['codeVerifier'] function generateAndStoreOAuthState<OST extends OptionalOAuthStateType>( optionalStateTypes: OST[], provider: ProviderConfig, res: ExpressResponse ): OAuthState

sodic · 2024-06-05T08:57:33Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

@@ -32,37 +34,43 @@ export function generateAndStoreOAuthState<ST extends StateType>(
  return result;


Github doesn't allow me to select the function's entire body, but the comment applies to all of it.

Recently, when reading Effective TS, I learned a couple of new things we can apply here:

Create objects all at once

Know how to iterate over objects

I won't repeat the item's content here, but here's how the code looks like after we apply:

const shouldGenerateCodeVerifier = optionalStateTypes.includes( 'codeVerifier' as OST ) const result = { state: generateState(), ...shouldGenerateCodeVerifier && { codeVerifier: generateCodeVerifier() }, } let key: keyof typeof result for (key in result) { setOAuthCookieValue(provider, res, key, result[key]) } return result

If you implement some of the stuff from the state types comment, maybe it even makes sense to go full ~~retard~~ functional:

const stateGenerators: { [name in keyof OAuthState]: () => OAuthState[name] } = { state: generateState, codeVerifier: generateCodeVerifier, } // ... const stateTypes: StateType[] = [...optionalStateTypes, 'state'] const result = stateTypes.reduce( (result, stateType) => ({ ...result, [stateType]: stateGenerators[stateType](), }), {} as OAuthState ) let key: keyof typeof result for (key in result) { setOAuthCookieValue(provider, res, key, result[key]) } return result

This might be pushing it a little tho (although it is open-closed for new optional states). I'm just giving ideas, it's your call. The current version of the code is perfectly fine to me.

I've adjusted the code to be simpler and generate the result all the once :D

sodic · 2024-06-05T09:04:52Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/user.ts

+  userSignupFields: UserSignupFields | undefined;
+  req: ExpressRequest;
+  accessToken: string;
+  oAuthState: { [name in RequiredStateType]: string };


Another place where i'd put a record.

sodic · 2024-06-05T09:10:43Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/handler.ts

+        const redirectUri = await finishOAuthFlowAndGetRedirectUri({
+          provider,
+          providerProfile,
+          providerUserId,
+          userSignupFields,
+          req,
+          accessToken,
+          oAuthState,
+        })


This is a lot of arguments spanning different levels of abstraction. I see why they're all necessary though.

Do you think it maybe makes sense grouping them into a couple of objects and passing them around like that? This will depend on semantic connection between the arguments (are they always dispatched together, is one batch used for one thing and the other batch for a different thing, etc.).

You'll judge this better than I can.

sodic · 2024-06-05T09:18:08Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/state.ts

-  stateTypes: ST[],
+export type OptionalStateType = 'codeVerifier';
+
+export function generateAndStoreOAuthState<OST extends OptionalStateType>(


I understand the purpose of the generic, you want to connect the argument's type to the return type.

However, using the generic complicates the rest of the code (for example, when defining callbacks such as getAuthorizationUrl, you can't just use OAuthState but must instead query the ReturnType of a different function).

This might be necessary to prevent user errors that would cause unexpected behaviour. I have a feeling it is necessary (there seems to be a connection over OST while creating provider configs) but am not 100% sure.

But if user's don't get too much from this extra type safety (do they need to know about specific optional state types they're using?), I recommend dropping the generic and just using OptionalStateType.

As mentioned, I don't know whether which is the case and, if I were to bet, I'd say that it was necessary. I can try it out and see, but you'll know right away.

NOTE: When I say users, I mean "Wasp users and calling code", not only Wasp users.

sodic · 2024-06-05T09:28:07Z

waspc/data/Generator/templates/server/src/auth/providers/oauth/handler.ts

  /*
    The function that returns the URL to redirect the user to the
    provider's login page.
  */
-  getAuthorizationUrl: Parameters<typeof createOAuthLoginHandler<ST>>[2],
+  getAuthorizationUrl: Parameters<typeof createOAuthLoginHandler<OST>>[2]


Disclaimer: talking about code again

Ok, I'm guessing this is where the relationship I suspected of in the previous comment shines through.

Another Effective typescript tip: Ideally, we'd want the types and and the user facing code to dictate the types/structure.

User-facing type --> internal functions

For these fields, that does happen, but with extra steps:

User-facing type (optionalStateTypes) --> internal functions (createOAuthLoginHandler) --> User-facing type (getAuthorizationUrl)

Can we somehow flip this to:

User-facing types (all of them) --> internal functions

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>

sodic · 2024-06-05T10:39:15Z

waspc/data/Generator/templates/sdk/wasp/server/auth/hooks.ts

+/* On After Signup Hook */
+export type OnAfterSignupHookFn = (
+  params: OnAfterSignupHookFnInput,
+) => Promise<void>


What happens when a user wants the hook to be a non-async function.

Yep, we need to account for that 👍

I've adjusted the return type to allow for async and sync functions.

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>

infomiho commented Apr 24, 2024

View reviewed changes

infomiho marked this pull request as ready for review May 2, 2024 12:25

infomiho requested a review from sodic May 3, 2024 11:41

infomiho force-pushed the miho-auth-hooks-2 branch from 72dc06f to ff5ce18 Compare May 8, 2024 11:48

infomiho commented May 8, 2024

View reviewed changes

web/docs/auth/auth-hooks.md Outdated Show resolved Hide resolved

infomiho commented May 8, 2024

View reviewed changes

web/docs/auth/auth-hooks.md Outdated Show resolved Hide resolved

infomiho commented May 8, 2024

View reviewed changes

web/docs/auth/auth-hooks.md Outdated Show resolved Hide resolved

infomiho force-pushed the miho-auth-hooks-2 branch from 2f39592 to 382f643 Compare May 9, 2024 10:40

infomiho force-pushed the miho-auth-hooks-2 branch from 382f643 to 9bcd660 Compare May 22, 2024 09:09

infomiho commented May 23, 2024

View reviewed changes

sodic reviewed Jun 3, 2024

View reviewed changes

sodic requested changes Jun 5, 2024

View reviewed changes

infomiho added 14 commits June 5, 2024 12:12

WIP auth hooks

7321db6

e2e tests

0bdcaa5

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>

Fixes unit tests

de1472e

Updates changelog

f62f6b1

Auth Hooks docs

e661d9a

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>

Updates docs with hookName

7973d51

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>

Update e2e tests to use auth hooks. Cleanup old auth e2e tests.

a175efa

Playing around with oauth state WIP

d9c9d14

Adds diagrams

8c9442b

Remove "onAfterOAuthTokenReceived" hook

09b4d41

Adds accessToken to "onAfterSignup" hook

e6cdb3c

Passing in OAuth state into the hooks

22a07f6

e2e tests

6aa946c

Update docs

99bad30

infomiho added 4 commits June 5, 2024 12:12

Make state required. Update params shape.

a94e42f

Updates docs

8f1451b

Cleanup

1ca9e55

Update diagrams

bdd7e70

infomiho force-pushed the miho-auth-hooks-2 branch from 35d3c07 to bdd7e70 Compare June 5, 2024 10:12

infomiho added the auth label Jun 5, 2024

sodic reviewed Jun 5, 2024

View reviewed changes

infomiho added 2 commits June 5, 2024 16:24

Adds auth hook headless tests (#2022)

95fee60

PR comments

0b93adc

infomiho force-pushed the miho-auth-hooks-2 branch from 46e987f to 0b93adc Compare June 6, 2024 16:25

infomiho added 6 commits June 6, 2024 19:06

Cleanup

7c4499d

PR comments

810f4f5

Docs cleanup

93a1e3b

Simplify the diagrams

30ddf94

Cleanup

f3f95f7

Simplify types

74f42c6

Signed-off-by: Mihovil Ilakovac <mihovil@ilakovac.com>


		For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:

		```wasp


		## Available Hooks

		For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:

	For every auth hook you want to use, you need to declare it in the `auth` dict in your Wasp file:
	You must first declare all desired hooks in your Wasp file:


		if (stateTypes.includes('codeVerifier' as ST)) {
		if (optionalStateTypes.includes('codeVerifier' as ST)) {

		@@ -32,37 +34,43 @@ export function generateAndStoreOAuthState<ST extends StateType>(
		return result;

Auth Hooks #1993

Are you sure you want to change the base?

Auth Hooks #1993

Conversation

infomiho commented Apr 24, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho commented May 9, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho Jun 6, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

infomiho commented Apr 24, 2024 •

edited

infomiho commented May 9, 2024 •

edited

infomiho Jun 6, 2024 •

edited

sodic left a comment •

edited