Creating a user and authenticating at once (with passwordless login)

[einarpersson]

Hi!

Context

• We are using a OTP only login flow with a long magic link.
• We use PocketBase with JS hooks

We have two flows for signing up

1. Initiated by user

The user goes to a general login/signup page and just enters the email, which will create a temporary user if not existing, sending a otp email to the user email, and on clicking that link they will verify the user and get logged in. Ephemeral (unverified) users are cleaned up when the otp itself expires.
THIS WORKS

2. Initiated by us

But we also want to support the case of us sending out an invitation email. We could of course send an email with some link to the signup-page described above, and somehow leverage it. But then the users experience would be to "first get one mail for the invitation, and then have to open yet another mail to verify that you are in control of that mail address" The user has already proven that it has control of that email address.

So the question is, can we provide a nicer user experience for flow 2 without completely sacrificing security? I'm trying to figure out what APIs i can play with here.

Is it possible to initiate a OTP request from pocketbase (js)? I was looking for something like record.createNewOtp() I did find newOTP interface but that seems to be go-only? (or? when the docs are go only, does that mean that it exists but only in go, despite being in the jsvm docs?).

I suppose we can just call the web api also, but it would be nice not have to do a external $http.send( if I want to do it from within pb_hooks (for example in a hook that is triggered when a entry is added to the invites collection).

If above not works (leveraging OTP both for login and for invite) my plan is it possible to use the record.newAuthToken() in a custom route to first (a) create a user and then (b) return a token / set a cookie which can be parsed by js-sdk

[ganigeorgiev]

Is it possible to initiate a OTP request from pocketbase (js)? I was looking for something like record.createNewOtp() I did find newOTP interface but that seems to be go-only?

There is no binding for core.NewOTP in the JSVM at the moment but I'm not sure if it is really necessary.

core.OTP is a typed Go proxy struct with some helper methods like HasExpired but under the hood it is a regular Record, meaning that you can create it on your own. This could look something like:

const user = ...

// generate a password similar to the default one
// OR if you are using it as a "magic link" change it to something more complex 
const otpPassword = $security.randomStringWithAlphabet(user.collection().otp.length, "1234567890") 

const otpCollection = $app.findCollectionByNameOrId("_otps")

// create OTP Record
const otp = new Record(otpCollection)
otp.set("collectionRef", user.collection().id)
otp.set("recordRef", user.id)
otp.set("password", otpPassword)
$app.save(otp)

// send an email with the OTP
$mails.sendRecordOTP($app, user, otp.id, otpPassword)

when the docs are go only, does that mean that it exists but only in go, despite being in the jsvm docs?

Only the bindings under the "PocketBase" section can be initialized in the JSVM.

Everything else (aka. the types under "Namespaces") is a TypeScript type/interface that mirrors the Go equivalent package definition (ideally only for the used fields and methods).

For example, compare the following docs:

• JSVM: https://pocketbase.io/jsvm/modules/textproto.html
• Go: https://pkg.go.dev/net/textproto

The JSVM shows that there is a MIMEHeader interface but that doesn't mean that such JavaScript function/constructor/object/etc. exist in the global JSVM context, aka. there is no new MIMEHeader().

Why it is shown in the docs if you can't initialize it?
Because some other JSVM binding may return a result of type textproto.MIMEHeader (or an object that has field with that type) and while you can't initialize it you can access its methods and fields.

[einarpersson]

Thank you, now I understand better. I was always confused regarding that part of the JSVM reference.

Just a short clarification: I suppose it is not possible to modify the duration of individual OTP records? i.e. if I use OTP both for login and for invite then they would have to have the same duration. As this is probably not what I want, I guess another solution would be to create a invites collection mirroring _otps and the pattern above (and handling the email sending and any cleanup myself).

[ganigeorgiev]

I suppose it is not possible to modify the duration of individual OTP records?

No, all OTPs are checked against the configured collection's OTP duration value.

A hacky workaround could be to manually set created/updated in the "future - collection.otp.duration", something like:

const min = 60000000000 // nanosec
const date = new DateTime().add(10*min - user.collection().otp.durationTime())

// autodate type fields can be set manually only with setRaw
otp.setRaw("created", date)
otp.setRaw("updated", date)
...

But if you are going to have OTPs > 5min, make sure to set their password to something more complex to prevent bruteforce attempts.