There are two use cases for obtaining an Organization:
1) For an API call in a controller. (e.g. AlertController)
2) For a back-end organization-agnostic component. (e.g. JobCoordinator)
At the moment we have an OrganizationRepository which combines these two use cases. However, there should be a separation of translating "session" state into an Organization vs looking-up or scanning from a repository (MP specific or external).
All this should be kept light-weight and extensible to allow MP clients to plug-in appropriate external systems or to integrate MP itself into another product leveraging its auth N/Z.
The following is a skeleton proposal of how we should proceed based on the constraints outlined above.
1) Refactor Organization into OrganizationReference which should contain an OrganizationRepository and a UUID (the organization id). All existing domain repositories (e.g. alert, expression, etc.) should accept OrganizationReference instead of Organization. The class should offer abstracted look-up of the actual Organization (via the OrganizationRepository).
2) Create a SessionManager interface and DefaultSessionManager which is injected into the controllers via configuration (reference.conf). Remove the HttpRequest to Organization translation from OrganizationRepository and put it into SessionManager. Except we'll nest OrganizationReference inside an internal model object called Profile. Remove the OrganizationRepository from all controllers (they should not need it anymore).
3) Create UserReference similar to OrganizationReference. Update the OrganizationRepository to allow a user's organization to be fetched. In DefaultSessionManager look for the user and organization id in the Play session cookie. If found, create a profile for those references. If not found, create a new user id and reference and query the organization repository for it.
** Alternative here would be to create a UserRepository to encapsulate the mapping of user to organization (even if they are backed by the same physical repository).
4) Update the contract between the controllers and the SessionManager to allow the SessionManager to:
a) Pull headers/cookies from the request
b) Write cookies to the reply
c) Redirect the request w/o executing the remainder of the controller logic
** DefaultSessionManager will only do a) and b); but a real session manager would request auth N before establishing the session.
There are two use cases for obtaining an
Organization
:1) For an API call in a controller. (e.g. AlertController) 2) For a back-end organization-agnostic component. (e.g. JobCoordinator)
At the moment we have an
OrganizationRepository
which combines these two use cases. However, there should be a separation of translating "session" state into anOrganization
vs looking-up or scanning from a repository (MP specific or external).All this should be kept light-weight and extensible to allow MP clients to plug-in appropriate external systems or to integrate MP itself into another product leveraging its auth N/Z.
The following is a skeleton proposal of how we should proceed based on the constraints outlined above.
1) Refactor
Organization
intoOrganizationReference
which should contain anOrganizationRepository
and aUUID
(the organization id). All existing domain repositories (e.g. alert, expression, etc.) should acceptOrganizationReference
instead ofOrganization
. The class should offer abstracted look-up of the actualOrganization
(via theOrganizationRepository
).2) Create a
SessionManager
interface andDefaultSessionManager
which is injected into the controllers via configuration (reference.conf
). Remove theHttpRequest
toOrganization
translation fromOrganizationRepository
and put it intoSessionManager
. Except we'll nestOrganizationReference
inside an internal model object calledProfile
. Remove theOrganizationRepository
from all controllers (they should not need it anymore).3) Create
UserReference
similar toOrganizationReference
. Update theOrganizationRepository
to allow a user's organization to be fetched. InDefaultSessionManager
look for the user and organization id in the Play session cookie. If found, create a profile for those references. If not found, create a new user id and reference and query the organization repository for it.** Alternative here would be to create a
UserRepository
to encapsulate the mapping of user to organization (even if they are backed by the same physical repository).4) Update the contract between the controllers and the
SessionManager
to allow theSessionManager
to:a) Pull headers/cookies from the request b) Write cookies to the reply c) Redirect the request w/o executing the remainder of the controller logic
**
DefaultSessionManager
will only doa)
andb)
; but a real session manager would request auth N before establishing the session.