Add ensure_user_stays_in_vendor_bucket to all the controllers.

[jmax-gsa]

🎫 Ticket

Link to the relevant ticket:
LG-14658

🛠 Summary of changes

Added a before action to all of the document capture controllers to make sure the user stays in their assigned vendor bucket. i.e., if we send them to Socure, they can't use LN by manually entering the Socure document capture URL, and vice-versa.

📜 Testing Plan

** IN PROGRESS **

Bring up the app running locally, with access from your phone via WiFi
HOST=0.0.0.0 make run

• Set your application.yml file to use Lexis Nexis (see below). Begin IdV on your computer, and select hybrid handoff. When you reach the document capture page, verify that the page you are on is /idv/hybrid_mobile/document_capture
• Manually enter the path for Socure document capture /idv/hybrid_mobile/socure/document_capture. Verify that you are redirected back to the same page as on the previous step.
• Cancel IdV.
• Begin IdV on your phone (i.e. do not use hybrid handoff). When you reach the document capture page, verify that the page you are on is /idv/document_capture
• Manually enter the page for Socure document capture /idv/socure/document_capture. Verify that you are redirected back to the same page as on the previous step
• Cancel IdV
• Set your application.yml file to use Socure (see below). Begin IdV on your computer, and select hybrid handoff. When you reach the document capture page, verify that the page you are on is /idv/hybrid_mobile/socure/document_capture
• Manually enter the path for Lexis Nexis document capture /idv/hybrid_mobile/document_capture. Verify that you are redirected back to the same page as on the previous step.
• Cancel IdV.
• Begin IdV on your phone (i.e. do not use hybrid handoff). When you reach the document capture page, verify that the page you are on is /idv/socure/document_capture
• Manually enter the page for Lexis Nexis document capture /idv/document_capture. Verify that you are redirected back to the same page as above.
• Cancel IdV

The two relevant application.yml values to use LN are:

doc_auth_vendor: 'lexis_nexis'
doc_auth_vendor_default: 'lexis_nexis'

The two relevant application.yml values to use Socure are:

doc_auth_vendor: 'lexis_socure'
doc_auth_vendor_default: 'lexis_socure'

[mitchellhenke]

This seems like it could be kind of brittle, can we do a comparison on the expected doc_auth_vendor and the calculated doc auth vendor instead closer to the controller actions and use the context there to pass in the relevant variables?

before_action ->{ redirect_to_correct_vendor(Idp::Constants::Vendors::SOCURE, true) }, only: [:relevant_action]
before_action ->{ redirect_to_correct_vendor(Idp::Constants::Vendors::SOCURE, false) }, only: [:other_relevant_action]
before_action ->{ redirect_to_correct_vendor(Idp::Constants::Vendors::LEXIS_NEXIS, true) }, only: [:relevant_action]
before_action ->{ redirect_to_correct_vendor(Idp::Constants::Vendors::LEXIS_NEXIS, false) }, only: [:other_relevant_action]

# concern.rb
def redirect_to_correct_vendor(vendor, in_hybrid_mobile)
      expected_doc_auth_vendor = doc_auth_vendor
      return if vendor == expected_doc_auth_vendor
      path = case expected_doc_auth_vendor
      when Idp::Constants::Vendors::SOCURE
        in_hybrid_mobile ? idv_hybrid_mobile_socure_document_capture_path
                         : idv_socure_document_capture_path
      when Idp::Constants::Vendors::LEXIS_NEXIS, Idp::Constants::Vendors::MOCK
        in_hybrid_mobile ? idv_hybrid_mobile_document_capture_path
                         : idv_document_capture_path
      end
   redirect_to path
end

[jmax-gsa]

Better. Thanks.

[jmax-gsa]

Leaving the actions clauses out, because based on conversation with @amirbey when refining this, he really does mean it to check all the actions.

[mitchellhenke]

In reading through the controllers, there's only one display action it seems? Is there value in redirecting the update request that should never happen? Should that respond with an error?

One of the controllers already has the following, which might conflict?

      case doc_auth_vendor
      when Idp::Constants::Vendors::SOCURE
        redirect_to idv_socure_document_capture_url
      when Idp::Constants::Vendors::LEXIS_NEXIS, Idp::Constants::Vendors::MOCK
        render :show, locals: extra_view_variables
      end

[jmax-gsa]

All of these are "should never happen" conditions; I don't see that any one has priority over the others.

[jmax-gsa]

That code was the result of addressing similar concerns during the initial Socure implementation. Removed, as it is now redundant.

[mitchellhenke]

All of these are "should never happen" conditions; I don't see that any one has priority over the others.

Ah, with the understanding that this is more about handling circumvention, is there a way to add these checks to step_info so that confirm_step_allowed can handle it automatically?

[mitchellhenke]

(apologies, unresolved this thread following the change in my understanding)

[jmax-gsa]

Hmm. Will look into. Implemented your suggestion above; it took a little tweaking to allow for the mock proofer.
But putting it in confirm_step_allowed is an interesting thought.

[jmax-gsa]

Hit the timebox for doing this with the step_info and confirm_step_allowed approach. It's a good idea, and we have a ticket for it: LG-14990

[amirbey]

Works as expected ... LGTM 👍🏿

one small request in comment section 😄

[amirbey]

Can we add this quick test to the other document capture feature tests (standard, standard socure, and hybrid socure)?

[jmax-gsa]

Added to the standard flow feature spec. Will bring up Socure feature specs as a 16th minute today.