The problem with the current implementation is the number of authorizations shouldn't have a practical limit. However, while the query to returns clients is paginated, the client attributes which are returned by properties is currently returning all of the authorizations.
"""
The list of authorizations where the client is the subject.
"""
authorizationsAsSubject: [Authorization]
"""
The list of authorizations where the client is the audience.
"""
authorizationsAsAudience: [Authorization]
The update that needs to be performed is to add parameters to both of these to enable pagination.
"""
The number of items to return starting after the cursor specified by 'after'. Used for forward pagination.
"""
first: Int
"""
The cursor after which to return the items. Used for forward pagination.
"""
after: String
"""
The number of items to return ending before the cursor specified by 'before'. Used for backward pagination.
"""
last: Int
"""
The cursor before which to return the items. Used for backward pagination.
"""
before: String
This is a breaking change and will impact serviceauthcentralweb since that UI will now need to support pagination. That is if the pagination parameters are required like they are for clients. The thing is, the way that front end is currently implemented implementing pagination will be a bit tricky.
Given the authorizations are handled in an independent collection this also requires changing the interface for retrieving this data which is where the decision on if this is a breaking change is made. I'd bias towards yes, this should limit the number of authorizations returned to a reasonable number, but the front end UI could just artificially limit that number as a stop gap and a separate issue filed to fix that limitation.
/**
* Retrieves an iterator over Authorization documents for a specific subject.
*
* @param subject the clientId representing the subject of the authorization.
* @return an Iterator of Authorization documents for the specified subject.
*/
Iterator<Authorization> getAuthorizationBySubject(String subject);
/**
* Retrieves an iterator over Authorization documents for a specific audience.
*
* @param audience the clientId representing the audience of the authorization.
* @return an Iterator of Authorization documents for the specified audience.
*/
Iterator<Authorization> getAuthorizationByAudience(String audience);
The problem with the current implementation is the number of authorizations shouldn't have a practical limit. However, while the query to returns clients is paginated, the client attributes which are returned by properties is currently returning all of the authorizations.
The update that needs to be performed is to add parameters to both of these to enable pagination.
This is a breaking change and will impact serviceauthcentralweb since that UI will now need to support pagination. That is if the pagination parameters are required like they are for clients. The thing is, the way that front end is currently implemented implementing pagination will be a bit tricky.
Given the authorizations are handled in an independent collection this also requires changing the interface for retrieving this data which is where the decision on if this is a breaking change is made. I'd bias towards yes, this should limit the number of authorizations returned to a reasonable number, but the front end UI could just artificially limit that number as a stop gap and a separate issue filed to fix that limitation.