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

feat(guardian): rich consent supports authorization details #126

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

cgcladeraokta
Copy link
Contributor

@cgcladeraokta cgcladeraokta commented Feb 13, 2025

By submitting a PR to this repository, you agree to the terms within the Auth0 Code of Conduct. Please see the contributing guidelines for how to create and submit a high-quality PR for this repo.

Description

Add support to authorization_details property in the Rich Consent record.

Adds a demo to the sample app that accepts "payment_initiation" authorization details type and displays the details in the consent screen.

Screenshot 2025-02-18 at 15 26 10

References

Include any links supporting this change such as a:

  • GitHub Issue/PR number addressed or fixed
  • Auth0 Community post
  • StackOverflow post
  • Support forum thread
  • Related pull requests/issues from other repos

If there are no references, simply delete this section.

Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Please include any manual steps for testing end-to-end or functionality not covered by unit/integration tests.

Also include details of the environment this PR was developed in (language/platform/browser version).

  • This change adds test coverage for new/changed/fixed functionality

Checklist

  • I have added documentation for new/changed functionality in this PR or in auth0.com/docs
  • All active GitHub checks for tests, formatting, and security are passing
  • The correct base branch is being used, if not the default branch

@cgcladeraokta cgcladeraokta changed the title feat(rich-consents): support authorization details feat(guardian): rich consents supports authorization details Feb 18, 2025
@cgcladeraokta cgcladeraokta changed the title feat(guardian): rich consents supports authorization details feat(guardian): rich consent supports authorization details Feb 18, 2025
@cgcladeraokta cgcladeraokta marked this pull request as ready for review February 18, 2025 12:45
}
```

Or, if you prefer to work with typed objects, you can use the filter helper passing a Class that has been annotated with `@AuthorizationDetailsType("[type]")`.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should be more forward in encouraging this as the default behaviour. See the wording that I put in the iOS README for comparison

}
```

Or, if you prefer to work with typed objects, you can use the filter helper passing a Class that has been annotated with `@AuthorizationDetailsType("[type]")`.
Copy link
Contributor

@sam-muncke sam-muncke Feb 26, 2025

Choose a reason for hiding this comment

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

I think we probably need to make a reference to the GSON docs here. Whilst we don't explicitly expose any dependency on Gson objects in our inteface, our implementation is implicitly coupled to it and the types they define need to conform to the rules for deserialization (and can leverage things like their attributes for customization)

}

public String getType() {
return "payment_initiation";
Copy link
Contributor

Choose a reason for hiding this comment

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

Not keen on this. I feels a bit redundant declaring this statically since we are using the annotation. I know its just an example and it ultimately will get populated to this but I think it might lead to confusion by someone using this as a reference. I'd let this be a data value like the others and let the serialization populate it.

@@ -79,16 +89,38 @@ protected void onCreate(Bundle savedInstanceState) {

setupUI();

if (notification.getTransactionLinkingId() != null) {
Copy link
Contributor

@sam-muncke sam-muncke Feb 26, 2025

Choose a reason for hiding this comment

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

This is much nicer than having the separate activities with all the logic in Main. This can probably be tidied up a bit though but adding so private methods to reduce the nesting a bit. You also have 3 code paths that all ultimately call updateUI() - pretty sure you can simplify

Log.e(TAG, "Error requesting consent details", e);
}
}
startActivity(NotificationActivity.getStartIntent(this, notification, enrollment));
Copy link
Contributor

Choose a reason for hiding this comment

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

Much better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants