Repository navigation
Conversation
tcannonfodder
left a comment
There was a problem hiding this comment.
I also need to review the updated error message when I'm at my desk
|
|
||
| def set_relying_party_in_request_env | ||
| raise "need to define relying_party for this SessionsController" | ||
| raise NotImplementedError, "need to define set_relying_party_in_request_env for #{self.class.name}" |
There was a problem hiding this comment.
As annoying & confusing as it can be, there are both semantic & practical reasons to not use NotImplentedError, see: https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd7228e5.
Some possible candidates
- Leave as-is
RuntimeErrorNoMethodError
There was a problem hiding this comment.
Oooh, ok. Good catch. Fixed
Ack, I know I had this conversation with @heliocola, but I can't find it 😬 The gist is that I don't want this gem to be too magical, which is one of the problems I have with devise as a whole. Since the relying party is the core for the entire WebAuthn flow; the app should be responsible for:
I know it can feel like a bit of overkill, but it has the benefits of:
|
totally agree with this statement. However, I think this is the perfect candidate(there are few) to actually have a generic implementation for. Mainly because I don't see how the implementation for it could reasonably be any different. |
Hmmm; let me think on that, you make a good point. I'm also curious about those other places you think a generic implementation would be useful; feel free to make an issue! |
There was a problem hiding this comment.
@Vagab I actually moved set_relying_party_in_request_env into Warden::WebAuthn::RackHelper in #29 (7b7d501).
Can you close this PR and make a new one based on that branch, with this error message being on the relying_party method directly, see:
7b7d501#diff-c88c685935abcec7655c75a59b34681909226e6fa4088f253427d5ddefef1c99R72
I think
NotImplementedErrorwith class name reads better. Also, the message was sayingrelying_partywhich is confusing in this context, since even if it's implemented we'll still get an error.On a separate note, @tcannonfodder, why don't we just write a default implementation in, say,
Warden::WebAuthn::StrategyHelpers? I don't think many users will have a better use for it thanHappy to make a pr