Install as npm install or build & copy dist?

[SGarno]

What is the intent for sk-auth going forward? Right now it seems that it is set up to be pulled from github and built, then take the dist directory and put that into your project. Is that how this is to operate?

I tried doing an npm install but it creates only shell package.json files with references to '../dist/'.

Secondly, after pulling the source and doing an npm run build or yarn build generates commonJS in the index.js output, which does not work with vanilla SvelteKit/vite. vitejs/vite#2579.

Interestingly, I tried changing the module and and target in tsconfig.json to 'es6' instead of 'esNext' and it didn't fix the issue. I am not too familiar with tsc for making this work.

[Dan6erbond]

SvelteKitAuth has actually been published to NPM since yesterday. You can install it via npm install sk-auth or yarn add sk-auth, but I still have to add that to the README.md and documentation when I get around to it!

As for the build process, it's now being handled with Rollup, which generates a dist/ folder with the output that mirrors the original folder structure and type definitions. I still need to figure out a way to merge types from src/*, src/client/* and src/providers/* to their own index.d.ts files, but the rest should work as I'm leveraging individual package.json files for sk-auth/client and sk-auth/providers which seems to be compatible with Vite and works in two of my projects.

See Cheeri-No.

[SGarno]

Strange...I tried npm before and it did not work...perhaps I was still trying it as the old name SvelteKitAuth.

Seems to be loading up ok, but I am struggling with getting it to work in my use case.

I have to make a call to a url, grab the Set-Cookie value and a setting value returned from that initial call.
If that setting returns a specific value, then it will also return the redirect url that I have to use authenticate, otherwise it will be a basic username/password authentication.

At the time of the first call, I don't know the redirect url so I cannot set OAuth2Provider config until I make a few round trips.

How would you suggest setting SKAuth up to handle this?

[Dan6erbond]

Ah yeah, unfortunately the name sveltekit-auth was already taken by another (looks like abandoned) project so I had to rename to sk-auth but I'm not sure if I'll rebrand it fully.

---

Okay, so if I'm understanding your use-case correctly you have the following flow:

1. Make a fetch() request to the auth provider and grab some values.
2. If the return contains a URL; redirect to that URL. Otherwise...?

This is where I'm a bit lost. Does that mean the user has to immediately pass username and password or can that be handled in the callback()?

If it's the latter, what I suggest you do is inherit from the base Provider class, and implement the something like this:

export class MyProvider extends Provider<MyProviderConfig> {
  constructor(config: MyProviderConfig) {
    super({
      id: "my-provider",
      ...config,
    });
  }

  async signin({ host }: ServerRequest<Locals, Body>, svelteKitAuth: Auth): Promise<EndpointOutput> {
    const { url } = fetch(...)

    if (url) {
      return {
        status: 302,
        headers: {
          // Redirect to provider authorization screen
          Location: url,
        },
      };
    }

    return {
      status: 302,
      headers: {
        // Redirect back to login screen with regular form
        Location: new URL("/login/credentials", svelteKitAuth.getBaseUrl(host)).href,
      },
    };
  }

  async callback({ method }: ServerRequest<Locals, Body>): Promise<CallbackResult> {
    if (method === "POST") {
      // Handle POST data and return user / redirect URL
      return [user, redirectUrl];
    } else {
      // Assume HTTP GET -> handle authorization response
      return [user, redirectUrl];
    }
  }
}

Since this isn't really an OAuth flow, more of a custom flow, I would also avoid naming it as such to avoid any confusion. Make sure the id you set in the config is unique!

Import to understand is that the callback() function is designed to handle the actual login process, and must return a user and redirect URL, whereas signin() simply initiates the flow, be that with a redirect to a third-party, or by generating a login screen which is roughly what I did in this sample implementation.

If you're logging-in with the username and password combination you should call the /api/auth/callback/my-provider route and handle the HTTP POST data, and if you're just initiating the flow to redirect to another provider you route them to /api/auth/signin/my-provider which does a safe redirect.

---

If you can think of other ways that gives providers more leverage over where the user and redirect is handled, I'm all ears since it was something that bothered me in NextAuth.js with the way it limited users to OAuth, credentials or email flows. One thing I'm considering is exposing a method in the Auth class along the lines of setToken() so that you can potentially return a set-cookie response in signin() as well.