[
http://jira.amdatu.org/jira/browse/AMDATU-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff resolved AMDATU-246.
------------------------------------
Resolution: Won't Fix
As discussed in AMDATU-247 there will be no centralized (login) context. Amdatu
Web provides generalized plugin mechanism for croscutting concerns and
frameworks suchs as oauth/shinding can build on top of that. If identity needs
to be propagated beyong servlet request context it is up to the specifi
framework or application code to deal with that in an appropriate way.
> Centralize login context information
> ------------------------------------
>
> Key: AMDATU-246
> URL: http://jira.amdatu.org/jira/browse/AMDATU-246
> Project: Amdatu
> Issue Type: Task
> Components: Amdatu Auth
> Affects Versions: 0.1.0
> Reporter: Ivo Ladage - van Doorn
> Assignee: Bram de Kruijff
> Fix For: 0.1.0
>
>
> In many parts of the software you need to know what user is currently logged
> in. Most of the times for authorization checks, in other cases to return
> user-dependent information. Examples of such components are:
> - Login REST service
> - oAuth authorize token servlet
> - UserAdmin REST service
> Note that for OpenSocial gadgets, this information is available in the
> SecurityToken send along with each request. That is fine for gadgets, but we
> need a similar mechanism for non-OpenSocial components. For that reason the
> username was added to the amdatu_token, which is send along with each
> request. This is the way it is currently implemented in the components above.
> However, this approach is not ideal for the following reasons:
> - Each service will need to retrieve the token from the request, check if the
> token is valid and decrypt the username from the token. This means that
> during the lifetime of a request, the same token may be validated and
> decrypted many times, while doing this only once should have been sufficient.
> - It depends on the HTTP request being available. An example of where this is
> problematic is CourseService.getAvailableCourses(Person). This service should
> in fact validate that the user that requests this information is a 'Teacher'.
> With the current implementation this is not possible, other then passing the
> HTTP request.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
