Support dynamic "origins" for this library for testing

[witwaycorp]

All,

I have a WebAuthn server using this library and was hoping to modify it so that I can support any sub-domain for the main website for some test scenarios I am working on. Example, the app is deployed to auth.example.com. I however would like to support any sub-domain of example.com like dev.example.com, prod.example.com, etc.

many thanks!

[abergs]

Not sure I follow - you can initiate a new instance of the library with the appropriate configuration for your origin.

[jackaboy7981]

This code should be part of startup right ?
If not, won't this cause service re-registration issues ?

In my use case i will be handling n-number of subdomains and the request should only be accepted from my subdomains.

[abergs]

Not using DI - or using DI with a "scoped" factory like above would match your requirements.

[Regenhardt]

For usage with DI, you can inject something like this FidoFactory and use your own URL-matching logic to decide which hosts you want to allow. Example usage in this UserController.

[HakooDesai]

According to spec, if you set RP ID as "example.com" during registration, it should support subdomains as login.example.com" and "auth.example.com". @abergs , Can you please confirm this?

[abergs]

@HakooDesai yes that's a valid behavior. The client (e.g. browser) will refuse to show passkeys outside of the rpid (only create/show keys for the current domain)

However - the RP server library may have their own logic for creating passkeys on multiple domains, e.g. multi tenant servers. Users would
Only be able to exercise the passkey on the domain it was created for.

I'm using domain freely here, as in domain + subdomains.