Improve PIV/CAC error messages (LG-3991)#4718
Conversation
There was a problem hiding this comment.
this controller was never able to reach these error branches, so I removed them.
app/forms/user_piv_cac_setup_form.rb
Outdated
There was a problem hiding this comment.
this method is never called
There was a problem hiding this comment.
combines the PivCacAuthenticationSetupErrorPresenter and PivCacAuthenticationLoginPresenter
There was a problem hiding this comment.
certificate.timeout and certificate.ocsp_error are no longer returned from PKI
bb24eea to
276f9e0
Compare
There was a problem hiding this comment.
this template was not being used, so it's been repurposed
There was a problem hiding this comment.
should we add an internal warn logging of what the missing error code was?
There was a problem hiding this comment.
all these try_again links are the same, WDYT of just generating it once at the top as a local or making a helper method for them?
def try_again_link
@view.link_to(t('instructions.mfa.piv_cac.try_again'), @try_again_url) if @try_again_url
end
There was a problem hiding this comment.
good call, added in 62f234b0e8b97f6e585ceeec70bb39e3ccc06f15
config/i18n-tasks.yml
Outdated
92c1379 to
e96a551
Compare
|
Translations added in e96a551 Spanish translations included a couple different ways to say "try again", so I had to split up those into two separate pieces of content. |
e96a551 to
461e171
Compare
461e171 to
a92d47f
Compare
In updating PIV/CAC error messages, I ended up shaving a pretty large yak. PIV/CAC has a few places it gets used:
PivCacSetupFromSignInController)The translations for 1 and 2 were separate, but don't appear to need to be. Sign in translations were less descriptive, "PIV/CAC did not work" instead of "Your PIV/CAC is expired", so the less descriptive translations were removed in favor of more helpful error messages.
The routing for 1 and 2 used different methods for displaying errors. Sign in used individual routes and templates, ex:
The PIV/CAC setup flow relied on
flash[:error_type]existing within the session to show errors, and would render a different template on thenewroute if it existed. It would also dynamically interpolate what was inflash[:error_type]into the i18n key, which could cause unhandled exceptions if we added a new error in PKI without a corresponding translation. That strategy also required not doing unused/missing key checks since they weren't explicitly used.I've tried to consolidate the error pages into using the same messaging, and moved the error message logic into a parameter added on the redirects. Some of the existing logic and routes will need to exist to prevent backwards incompatibility until the next release.
In draft mode to see how tests go and get new translations done