Remove passkey requirement

[dNayysantoe]

I’m setting up EmDash locally for development, and the initial admin/setup flow appears to require a passkey. That means I can’t complete first-time setup on machines or environments where WebAuthn/passkeys aren’t practical.

It would help to have a non-passkey bootstrap option for local/self-hosted development, for example:

• email + password with TOTP
• a dev-only fallback auth mode

I’m not asking to replace passkeys as the default. The issue is that there doesn’t seem to be a way to finish first-time local setup without them.

[endymion1818]

Same here. I don't have the ability to initiate a passkey on my laptop.

[Octolus]

That makes absolute no sense to enforce that even for Production, should at least have alternative methods.

[stayhc]

I completely agree, there should be alternative methods like traditional email + password with TOTP.

[simnaut]

I love passkeys. I hate that I can't get them to work with my linux systems and my iPhone. Having an alternate method would help until linux distros can get their act together

[techunleadit]

I've tons of passkey but with EmDash I'm getting
"Failed to verify admin setup"

[mateusz-zadorozny]

Yes, I was just about to make the same issue. I already have 3 new passkeys for local dev. We should be able to disable it easily.

[JonahFoster]

There is a workaround to get around the passkey requirement - http://localhost:4321/_emdash/api/setup/dev-bypass?redirect=/_emdash/admin

[alexasomba]

I love passkeys. I hate that I can't get them to work with my linux systems and my iPhone. Having an alternate method would help until linux distros can get their act together

If you love Passkey, simply install Bitwarden on a system or browser level as System App or Browser Extension.

[jstgnkl]

It seems the passkey component also does not respect X-Forwarded-Host and X-Forwarded-Proto? When self hosting the Origin stays localhost which prevents passkey's from being created. Currently it's only looking for Cloudflare like "getClientIp" function's.

[nathanmasson1]

I await alternative methods such as the traditional email + password.

[seslly]

It seems the passkey component also does not respect X-Forwarded-Host and X-Forwarded-Proto? When self hosting the Origin stays localhost which prevents passkey's from being created. Currently it's only looking for Cloudflare like "getClientIp" function's.

not a fix for no passkey request but should at least fix ^^ issue with the headers
#225

[jstgnkl]

It seems the passkey component also does not respect X-Forwarded-Host and X-Forwarded-Proto? When self hosting the Origin stays localhost which prevents passkey's from being created. Currently it's only looking for Cloudflare like "getClientIp" function's.

not a fix for no passkey request but should at least fix ^^ issue with the headers #225

Excellent, I just incorporated this fix but I had some issue's that it would redirect to localhost afterwards again. I created a working docker container with another fix for the passkey request if you want to try.
https://github.com/jstgnkl/docker-emdash

Edit: I honestly think this way of pushing the info through entrypoint.sh is very ugly, a fix to Emdash should be next step

[x-N0]

There is a workaround to get around the passkey requirement - http://localhost:4321/_emdash/api/setup/dev-bypass?redirect=/_emdash/admin

Let's document this under the development section of the README, developers testing out the capabilities must be able to surpass this requirement quickly and easily.

And in my personal opinion:
We should add a development way to just bypass login validation, not the entire setup flow, this in order for us to have a full testing capability of the portal, including the setup sliders.

[JakiChen]

This is my solution. Since my MacBook Pro is quite old and only runs macOS 11, I used GitHub Codespaces as my development environment. Password verification was done by referring to an answer I found on the Gemini forum. Please ensure the address is http://localhost:4321, not (http://127.0.0.1:4321). I discovered this while debugging the source code and checking the error messages.

Tip

Using Chrome DevTools' Virtual Authenticator (Recommended)

This is the most commonly used "escape route" for developers. You don't need real hardware support to simulate the creation and verification of a Passkey:

Open your project page in your browser (Chrome v138.0.7204.184).

Press F12 to open the Developer Tools.

Click the three dots in the upper right corner (More options) -> More tools -> WebAuthn.

In the pop-up WebAuthn panel, check "Enable virtual authenticator environment".

Add a virtual authenticator (select ctap2 for Protocol, internal for Transport, supporting Resident Key and User Verification).

Click "Create Passkey" again; the browser will directly use the virtual process and will no longer call macOS Touch ID.