-
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
feat(guardian): rich consent supports authorization details #126
base: master
Are you sure you want to change the base?
feat(guardian): rich consent supports authorization details #126
Conversation
Add support to `authorization_details` property in the Rich Consent record.
} | ||
``` | ||
|
||
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]")`. |
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.
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]")`. |
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.
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"; |
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.
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) { |
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 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)); |
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.
Much better
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.
References
Testing
Checklist