Fix DocAuthBaseStep throttle target#5354
Conversation
- Also add tpye checking to prevent this error in the future
| def throttled_else_increment | ||
| Throttle.for( | ||
| target: user_id, | ||
| user: current_user, |
There was a problem hiding this comment.
current_user doesn't always exist. See #user_id
There was a problem hiding this comment.
ah right, have to re-implement EffectiveUser
There was a problem hiding this comment.
comes from
which comes from
identity-idp/app/services/flow/flow_state_machine.rb
Lines 223 to 225 in a0fb189
So since user_session is sometimes nested, looks like no we can't just blindly use EffectiveUser :[
There was a problem hiding this comment.
So since
user_sessionis sometimes nested, looks like no we can't just blindly useEffectiveUser:[
Ah, okay. That makes more sense. Is it reasonable that EffectiveUser could also try to pick from user_session?
There was a problem hiding this comment.
If we really wanted to re-use the EffectiveUser mixin I bet we could modify it like this?
def effective_user_id
[
+ respond_to?(:flow_session) && flow_session[:doc_capture_user_id],
session[:doc_capture_user_id],
current_user&.id,
].find(&:present?)
endThere was a problem hiding this comment.
If we really wanted to re-use the EffectiveUser mixin I bet we could modify it like this?
Yeah, I think the idea with the mixin is to try a few potential places to grab the "current" user. Your suggestion is a bit more involved than I'd expected (vs. user_session[:doc_capture_user_id] I'd hoped it was). I'd be fine to just leave things as-is.
There was a problem hiding this comment.
one issue is that the steps/flow/world is very controller-like but are not actually controllers :[
Co-authored-by: Andrew Duthie <andrew.duthie@gsa.gov>
Spotted by @aduth in #5302 (comment)