-
Notifications
You must be signed in to change notification settings - Fork 23
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
SDP-1116 Support External_ID DRAFT PR (See TODO). reece #256
base: develop
Are you sure you want to change the base?
Conversation
stellar-disbursement-platform-backend-preview is available here: |
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 is looking pretty good, congrats!
I've shared some thoughts below on:
- some connection points that are missing (to make things easier for you)
- my opinion on where to do the final verification when validating the user in the SEP24 request.
Also, a nitpicky thing: indentation is looking a bit weird in some places. It looks like the old problem of spaces vs tabs indentation.
internal/serve/serve.go
Outdated
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.
You will need to propagate the UseExternalID config to the handler responsible for /wallet-registration/verification
, injecting it in:
stellar-disbursement-platform-backend/internal/serve/serve.go
Lines 435 to 441 in 977e0c3
r.With(sep24HeaderTokenAuthenticationMiddleware).Post("/verification", httphandler.VerifyReceiverRegistrationHandler{ | |
AnchorPlatformAPIService: o.AnchorPlatformAPIService, | |
Models: o.Models, | |
ReCAPTCHAValidator: reCAPTCHAValidator, | |
NetworkPassphrase: o.NetworkPassphrase, | |
EventProducer: o.EventProducer, | |
}.VerifyReceiverRegistration) |
internal/serve/httphandler/verifiy_receiver_registration_handler.go
Outdated
Show resolved
Hide resolved
Something went wrong with PR preview build please check |
Something went wrong with PR preview build please check |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
// Create a client to skip certificate verification (for testing) | ||
client := &http.Client{ | ||
Transport: &http.Transport{ | ||
TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, |
Check failure
Code scanning / CodeQL
Disabled TLS certificate check High
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
stellar-disbursement-platform-backend-preview is available here: |
Something went wrong with PR preview build please check |
Something went wrong with PR preview build please check |
What
This change will be deployed in a branch with a PR Preview pipeline to support Vibrant Assist in testing integration of supporting external_id in SDP registration deep link and sep24 post interactive deposit for partner integration.
The receiver’s invitation DeepLink should include the field external_id, containing the ID of that receiver_wallet
This code will not be merged for now. We should decide if we want to adopt this external-id field or not.
TBH, it could remove the need for an OTP step on our end, but we should discuss if we want that.
We need to validate the decision with @nando Vieira before concluding if this will be part of the official implementation, or if an optional field.
added some additional unit tests and verified all existing tests are passing.
Why
To support reconciliation of vibrant client (mobile phone) with SDP Host Customer ID by using an external_id field in the deeplink sent from the sdp host (SDP registration deep link). then this will be passed within SEP24 claims for reconciliation.
Known limitations / TODO
TBD - not yet part of this PR: When validating the wallet-registration, verify if the SEP24 incoming info contains the field: customer_id=external_id:hash(phone_number) Use the external_id to find the user in our database Hash the user’s phone number and compare it with the incoming hashed phone number It’s ok to send an informative response, so Vibrant can understand this well.
PR Structure
Thoroughness
Configs and Secrets
there is a new configuration option useExternalID (true/false) to make this optional. This has not yet been updated to helm charts yet until we determine if we plan to include this support in our standard release.
Release
not for release at this time. only for testing with Vibrant.
Deployment
Will be deployed only in a pr-preview pipeline at this time.