-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ProgressiveProofer refactor 1/N: ThreatMetrix #11420
Conversation
For now, just take the proof_with_threatmetrix_if_needed method + deps and move into a different file. [skip changelog]
it 'returns a ResultAdjudicator' do | ||
expect(proof).to be_an_instance_of(Proofing::Resolution::ResultAdjudicator) | ||
expect(proof.same_address_as_id).to eq(nil) | ||
context 'remote unsupervised proofing' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This diff is a little messy, but my goal is to, at the end of this refactor, have two top level contexts here: remote unsupervised proofing
and in-person proofing
.
app/services/proofing/resolution/plugins/threat_metrix_plugin.rb
Outdated
Show resolved
Hide resolved
spec/services/proofing/resolution/plugins/threatmetrix_plugin_spec.rb
Outdated
Show resolved
Hide resolved
spec/services/proofing/resolution/plugins/threatmetrix_plugin_spec.rb
Outdated
Show resolved
Hide resolved
if IdentityConfig.store.lexisnexis_threatmetrix_mock_enabled | ||
Proofing::Mock::DdpMockClient.new | ||
else | ||
Proofing::LexisNexis::Ddp::Proofer.new( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a heads up. Will be updating the config to add a "policy" attribute since we have decided for Authentication we will have a different policy. But otherwise. Taking a look this shouldn't affect our implementation much. may be a merge conflict depending on whats merged first.
Co-authored-by: Zach Margolis <[email protected]>
Allows much cleaner (1-line) checking of whether the plugin modifies cost counts
🛠 Summary of changes
Ahead of integrating a new vendor into the ProgressiveProofer, I'm going to do a series of PRs that extract code for individual vendors out into separate files/classes. I'm calling these "plugins" because I think that will ultimately describe the kind of architecture we're going for here, but for now these are basically just the old
proof_with_X_if_needed
methods extracted out into a new class with acall
method.Right now, each plugin's
call
method lays out exactly what its dependencies are. Each plugin also gets its own spec file, mainly focused on these primary scenarios:In some cases I am pulling spec code out of the existing ProgressiveProofer spec, and in some cases I am modifying it slightly to ensure it addresses the above scenarios.
This PR implements the first (and simplest) "plugin", which does the ThreatMetrix Session Query API call. There are not significant differences in implementation for the Remote and IPP flows here, and there's not really any "new" code being introduced--this is mostly moving existing code around.
See also
📜 Testing Plan
Provide a checklist of steps to confirm the changes.