dbAuth method behavior when disabled

We are using just the login setup with dbAuth:

    forgotPassword: { enabled: false },
    resetPassword: { enabled: false },
    signup: { enabled: false },
    webAuthn: { enabled: false },

There are a bunch of auth methods (https://github.com/redwoodjs/redwood/blob/fd00b281fdea89f9d2be72c6d6962b8c3ea53631/packages/auth-providers/dbAuth/api/src/DbAuthHandler.ts#L297C1-L313C1) that exist, but not all behave the same when disabled.
The signup, forgotPassword, or resetPassword flows results in a “… flow is not enabled” error as I’d expect. The four webAuthn methods, though do not: the Options methods return 404s and the other two return a missing module error. The token methods similarly error out, but not gracefully.

It would be nice if the disabled auth flows errored in a consistent manner. Unless I’m misunderstanding something?

Hey @klobetime :wave:

Without having looked into the implementation to see if there is a good reason for it, it does feel a little unclean to have the various different responses from the components that are disabled. I know the core team probably won’t be able to prioritise a fix/change to this ourselves as it doesn’t sound like a breaking bug at the moment. We’d certainly be more than happy to help out and review any PRs that tried to address this.

If you’d like to try out a PR for this then let me know how you get on and how we can be helpful.

I’ll loop @rob in here as the go to guy on dbAuth and we’ll see if he has anything more to say about it.

Reading things over again and seeing: The token methods similarly error out, but not gracefully. If you feel like you’re running into this as the default behaviour and it’s impacting your end product, e.g. it’s showing up in production apps, then feel free to open an issue on github if you think we should be treating this more seriously.

That was probably a combination of things: adding in the disable functionality after the rest of dbAuth was built, and then adding on WebAuthn support on top of that. Sounds like we didn’t do a great job of making sure all of that was consistent!

But to be fair, with those flows disabled and the UI removed, a regular user should never even try to hit those endpoints, and so would never see those errors or 404s—they’d only be visible to someone trying to probe your endpoints. I’m not too broken up about them seeing inconsistencies, but I agree that ideally they would all have similar behavior.

I don’t see that update as something we’d prioritize at the moment, but we do love getting PRs! :smiley: