Closed jeremyevans closed 5 months ago
Hello @jeremyevans!
First of all, thank you for the PR ❤️
However, this seems to be duplicate of #345 and #365 (some issues asking for that feature where open too such as #285, #320, #344 and #375).
Our gem has released support for handling multiple origins in v3.0.0. Please refer to our advanced configuration docs to see how to our gem provides a way for achieving that. We have moved away voluntarily from passing the expected origin, rp_id and others directly to the verification methods after discussion in #285.
Please let me know if that suits your use case and any questions you might have!
Switching to the new approach, if possible, would certainly require more significant changes to Rodauth, and I'm not sure I could keep Rodauth backwards compatible with such changes.
IMO, a design approach that promotes one API for simple cases but requires switching to a completely separate API for more advanced cases is suboptimal. One should aim for an approach that allows for gradual code changes in response to more gradually more complex needs.
I can see telling users to use the new WebAuthn::RelyingParty
for cases where the response #verify doesn't handle their needs, but since this change just passes existing arguments from the credential #verify to the response #verify, it seems low risk and makes it much easier to existing users to handle separate origins/relying party ids.
In any case, this isn't a big deal to me. Rodauth has always monkey-patched to the response #verify method to work correctly, and it can continue to do so. So it's fine with me if you close this.
Switching to the new approach, if possible, would certainly require more significant changes to Rodauth, and I'm not sure I could keep Rodauth backwards compatible with such changes.
IMO, a design approach that promotes one API for simple cases but requires switching to a completely separate API for more advanced cases is suboptimal. One should aim for an approach that allows for gradual code changes in response to more gradually more complex needs.
I can see telling users to use the new
WebAuthn::RelyingParty
for cases where the response #verify doesn't handle their needs, but since this change just passes existing arguments from the credential #verify to the response #verify, it seems low risk and makes it much easier to existing users to handle separate origins/relying party ids.In any case, this isn't a big deal to me. Rodauth has always monkey-patched to the response #verify method to work correctly, and it can continue to do so. So it's fine with me if you close this.
@jeremyevans I managed to come up with a POC for using our official approach for supporting multiple domains in rodauth
. It feels to me that that should be all you need to do, but I might be missing something as I have zero knowledge about rodauth
and how it works 😞
@santiagorodriguez96 Thank you very much. I'm happy to see that I was wrong, it wasn't a big change to switch to the new approach (though keeping compatibility will be a bit ugly until webauthn v2 support can be dropped). I'm going to close this.
The lack of support for this is the reason Rodauth currently overrides internal WebAuthn methods. I would like Rodauth to stop doing that, by having WebAuthn officially support this.
I've tested this with the following patch to Rodauth: