[
http://jira.dspace.org/jira/browse/DS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10159#action_10159
]
Bruc Liong commented on DS-109:
-------------------------------
We do extend the AuthenticationMethod. The reason why we need an extra servlet
(extending DSpaceServlet) is because it needs to process the headers
accordingly, very much similar to X509CertServlet.
The getSpecialGroups in the request is not populated when it is invoked from
other servlets (because we only protect /shibboleth-login with shibboleth and
shibboleth only reveals headers to the aforementioned protected URLs, not to
others). We can, though not required now anyhow, protect the whole DSpace with
Shibboleth but that will cause a slightly more complex configuration (perhaps
using "lazy session" mechanism in Shibboleth and the deployer needs to know
sections that they'd like to protect etc).
Apart from small jsp redirection, that servlet doesn't really do anything much
fancy, hence if you can think of a better way of extracting that out, we may be
able just to use other servlets in the future.
> Consistent treatment to users in special groups
> -----------------------------------------------
>
> Key: DS-109
> URL: http://jira.dspace.org/jira/browse/DS-109
> Project: DSpace 1.x
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.0, 1.5.1, 1.5.2
> Reporter: Bruc Liong
> Assignee: Andrea Bollini
> Fix For: 1.5.2
>
>
> We populate users into their groups via the use of "special groups" on the
> fly (as part of Shibboleth authN integration into DSpace) and had been
> noticing that the mapped users cannot gain access to their resources despite
> they have the aforementioned groups in the special group.
> Temporary fix for this is to persist the group membership, e.g.
> int[] groupIDs = AuthenticationManager.getSpecialGroups(context,request);
> for(int i=0;i<groupIDs.length;i++){
> Group g = Group.find(context, groupIDs[i]);
> //.....
> g.addMember(eperson);
> g.update();
> }
> This is not ideal, it would be better if the special groups are
> loaded/integrated into Group.isMember(eperson), or Group.isMember(groupid),
> etc calls. These isMember seem to be only honouring explicit users assigned
> in DB. Currently special groups only included in Group.allMemberGroupIDs and
> isMember(context,groupid).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
