Skip to content
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

Add Auth0 AppMetdata Struct #632

Merged
merged 4 commits into from
Jul 12, 2022
Merged

Add Auth0 AppMetdata Struct #632

merged 4 commits into from
Jul 12, 2022

Conversation

bbengfort
Copy link
Collaborator

@bbengfort bbengfort commented Jul 12, 2022

Scope of changes

This PR should fix the panic caused when logging in a user that has a nil app_metadata and ensure that the record is correctly populated. It introduces a struct AppMetadata that will allow us to serialize the app_metadata JSON in a structured fashion, ensuring keys and parsing are correct.

Type of change

  • bug fix
  • new feature
  • documentation
  • other (describe)

Acceptance criteria

This PR could really use an intense sanity check; particularly second eyes on the user-login logic. Happy to discuss if that would make things easier. I still need to test that this fixes the panic.

Author checklist

  • I have manually tested the change and/or added automation in the form of unit tests or integration tests
  • I have updated the dependencies list
  • I have recompiled and included new protocol buffers to reflect changes I made
  • I have added new test fixtures as needed to support added tests
  • Check this box if a reviewer can merge this pull request after approval (leave it unchecked if you want to do it yourself)
  • I have moved the associated Shortcut story to "Ready for Review"

Reviewer(s) checklist

  • Login algorithm makes sense
  • It makes sense how we might extend and add to the app_metadata
  • The claims using the same struct makes sense
  • Did I miss any test cases?

@bbengfort bbengfort requested a review from pdeziel July 12, 2022 03:45
@codecov-commenter
Copy link

codecov-commenter commented Jul 12, 2022

Codecov Report

Merging #632 (cdf630c) into main (ff8e01f) will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #632      +/-   ##
==========================================
- Coverage   45.85%   45.78%   -0.07%     
==========================================
  Files         543      544       +1     
  Lines       16151    16147       -4     
  Branches     1202     1201       -1     
==========================================
- Hits         7406     7393      -13     
- Misses       7621     7628       +7     
- Partials     1124     1126       +2     
Impacted Files Coverage Δ
.../github.com/trisacrypto/directory/pkg/bff/users.go 0.00% <0.00%> (-22.23%) ⬇️
...com/trisacrypto/directory/pkg/bff/auth/metadata.go 46.66% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff8e01f...cdf630c. Read the comment docs.

Copy link
Collaborator

@pdeziel pdeziel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me, I like the fact that we have a variety of test cases for marshaling and unmarshaling the auth0 response. I guess we will have to remember to update those if we add fields to auth0?

testnetID := claims.VASPs[testnet]
mainnetID := claims.VASPs[mainnet]
testnetID := claims.VASPs.TestNet
mainnetID := claims.VASPs.MainNet
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes a lot more sense than indexing into the map, can you update the above comment to reflect that this is a struct with default values now rather than a map?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

if err = s.SaveAuth0AppMetadata(*user.ID, *appdata); err != nil {
log.Error().Err(err).Str("user_id", *user.ID).Msg("could not save user app_metadata")
c.JSON(http.StatusInternalServerError, "could not complete user login")
return
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are now syncing the user app metadata at the end, this protects us from partial updates?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should only be two possible cases:

  1. The user is logging in for the first time and an organization is created for them
  2. The user needs the VASP ids updated from their organization

In case #1 - the following data is saved:

{
  "orgid": "uuid",
  "vasps": {
    "testnet": "",
    "mainnet": "",
  }
}

Case #1 should only happen once.

Because I moved the syncing to the end, case #2 is going to happen on every single login since I removed the MapEqual check. I debated whether or not we should do this -- it is safer, and logins are infrequent. However, we will eventually need some change detection to alert the front-end that the user needs to login again; so this is likely temporary.

@bbengfort
Copy link
Collaborator Author

This makes sense to me, I like the fact that we have a variety of test cases for marshaling and unmarshaling the auth0 response. I guess we will have to remember to update those if we add fields to auth0?

Agreed, if we add more fields we should add more cases; though I do think I went a little overboard with all the different combinations -- we don't have to test every single combination of empty and filled field!

@bbengfort bbengfort merged commit dd5455e into main Jul 12, 2022
@bbengfort bbengfort deleted the sc-6976/bugfix-users-login branch July 12, 2022 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants