Supabase auth?

[magick93]

Hello

I'm currently building on Supabase. Supabase uses postgres and also ships with its own auth.

The supabase auth is not an OIDC IDP. So I dont think it can be integrated as another 'social' style login.

I'm wondering if it would be possible, using a plugin, to replace the implementation of the default auth and use Supabase auth?

[michaelbromley]

Hi,
It should be possible - we have a pretty flexible mechanism for supporting external auth providers: https://docs.vendure.io/guides/core-concepts/auth/#external-authentication

[magick93]

Both Supabase and Vendure have session tables. So there may be a possibility to use the supabase auth, and add a trigger that adds a row to the vendure session table.

Sorry to keep throwing question out you. But I have a few more regarding some of the columns in the session table.

1. type - what is the purpose of this column? ANSWERED - this is the type of user, eg, anon or authenticated.
2. token - does this need to be of any particular format?

Thanks

[michaelbromley]

Hi,

Does the test-plugins mean they are recommended for testing?

It means I use that dir to test out certain plugin functionality.

token - does this need to be of any particular format?

No, not really. It's just a random string. Here's how it gets generated:

vendure/packages/core/src/service/services/session.service.ts

Line 321 in a817a1a

private generateSessionToken(): Promise<string> {

[magick93]

Thanks @michaelbromley

Regarding the user table:

CREATE TABLE vendure."user" (
	"createdAt" timestamp NOT NULL DEFAULT now(),
	"updatedAt" timestamp NOT NULL DEFAULT now(),
	"deletedAt" timestamp NULL,
	identifier varchar NOT NULL,
	verified bool NOT NULL DEFAULT false,
	"lastLogin" timestamp NULL,
	id serial4 NOT NULL,
	CONSTRAINT "PK_cace4a159ff9f2512dd42373760" PRIMARY KEY (id)
);

Is the identifier primarily intended to store email addresses? Is there a reason this is not a unique column?

Thanks

[michaelbromley]

Yes often it would be an email address, but sometimes other identifies are used such as phone number for OTP-based logins.

It is not unique at the DB-level because the entity is soft-deletable (deletedAt column), and enforcing a unique constraint would prevent someone signing up with the same identifier as a deleted user.

[magick93]

Thanks @michaelbromley

[siquick]

Did you implement this @magick93? Any recommendations for approach?