Closed kmayer closed 3 months ago
Hey there.
AuthorizedApplicationsController is used to index applications for which current resource owner is authorized. It doesn't render authorization date, but lists application creation date, yes.
You can override/extend the controller and try to return the date you need based on your requirements.
Since I don't see any issues here (I mean controller shows what is intended to be there) I'll close this issue
Steps to reproduce
AuthorizedApplications controller returns the date that the application was created, not the date that the authorization was created.
See also #279 and #109
I'd like to start with a design discussion rather than a PR, but I could do both. (by the way, I see that GitHub now has a discussion board option, separate form the issue board).
The way I see it, there are at least two possibilities:
belongs_to
an AccessGrant and AccessGrantshave_many
AccessTokens. This has several effects: Grants must live for the life of the authorization and there's an added foreign key. I don't expect ouraccess_grants
to grow very bit, perhaps 100,000 rows, but that does take a toll. And the foreign key needs to copied with every fresh AccessToken. When an authorization is revoked, we need someone to mark the grant for deletion, sincerevoked_at
is already in use.authorized_at
and that datum is propagated with every fresh AccessToken that is generate, much like scopes are now. This adds an extradatestamp
column toaccess_tokens
(while option 1 adds foreign reference key).Option 1 is a JOIN and requires some way to clean up the grant after the authorization has been revoked, Option 2 provides the data in the record, does not require any extra clean up logic, but duplicates it across the life of the authorization, and if anyone wanted to get other info from the Grant, they couldn't.
A third option is a variant on 2, but I just make my own custom modification to
access_tokens
and copy my newauthorized_at
column in one of the callback hooks, e.g.after_successful_authorization