[
https://issues.apache.org/jira/browse/CONNECTORS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779801#comment-13779801
]
Karl Wright commented on CONNECTORS-754:
----------------------------------------
There are usergroup.asmx methods that do the following:
- get user info given login name, which may no longer be very helpful
(GetUserInfo)
- get group names given login name (GetGroupCollectionFromUser)
- get role definitions given login name (GetRoleCollectionFromUser)
- get role definitions give a group name (GetRoleCollectionFromGroup)
The SharePoint doc (
http://msdn.microsoft.com/en-us/library/sharepoint/ms414400.aspx )describes how
permissions are granted via role definitions; there is apparently TWO supported
security models in SharePoint 2013 (one is deprecated), and some hint in
SharePoint 2010 that the new model is available, so I would presume both exist
in SharePoint 2010. Current implement of ManifoldCF SharePoint 2010 plugin
obviously supports the older model, but not the newer one, which is why this is
being worked on.
In the new model, the role definition controls the permission to perform
things. Some notes:
- There are two kinds of groups: domain groups, and SharePoint groups
- From SharePoint, you can find a user's SharePoint group association, but you
can't find the user's domain group association
- Role assignments in SharePoint are made between users, groups, or domain
groups, and role definitions
- Native SharePoint groups are not hierarchical
So, some conclusions:
(1) We WILL need a SharePoint authority to support this functionality.
(2) The SharePoint authority will need to obtain SIDs from Active Directory,
and native SharePoint access tokens from SharePoint.
(3) It's still not clear what a native SharePoint access token should be - this
depends on what is attached to the document. Also, not clear whether the
current Lists-based document metadata retrieval gets back sufficient
information to support the new model.
> SharePoint connector does not work with claim space authentication properly
> ---------------------------------------------------------------------------
>
> Key: CONNECTORS-754
> URL: https://issues.apache.org/jira/browse/CONNECTORS-754
> Project: ManifoldCF
> Issue Type: Bug
> Components: SharePoint 2010 MCPermissions extension, SharePoint
> connector
> Affects Versions: ManifoldCF 1.2
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: ManifoldCF 1.4
>
>
> When the SharePoint Connector is used against a SharePoint claimspace
> instance, it fails in the following ways:
> (1) The MCPermissions.asmx plugin is unable to write to the log.
> "EventLog.XXX" is not allowed, apparently, under this configuration option.
> (2) It is needing to write to the log, which indicates there is some hidden
> exception taking place that we aren't seeing.
> (3) When this fails, we're getting bad data returned from the list method,
> which causes ArrayIndexOutOfBoundsException's being thrown in the relative
> path manipulation code, due to the fact that the library/list name is not at
> the front of the relative path, e.g.:
> {code}
> FATAL 2013-07-17 19:24:57,927 (Worker thread '46') - Error tossed: String
> index out of range: 19
> java.lang.StringIndexOutOfBoundsException: String index out of range: 19
> at java.lang.String.substring(String.java:1955)
> at
> org.apache.manifoldcf.crawler.connectors.sharepoint.SharePointRepository$FileStream.addFile(SharePointRepository.java:1890)
> at
> org.apache.manifoldcf.crawler.connectors.sharepoint.SPSProxyHelper.getChildren(SPSProxyHelper.java:655)
> at
> org.apache.manifoldcf.crawler.connectors.sharepoint.SharePointRepository.processDocuments(SharePointRepository.java:1411)
> at
> org.apache.manifoldcf.crawler.connectors.BaseRepositoryConnector.processDocuments(BaseRepositoryConnector.java:423)
> at
> org.apache.manifoldcf.crawler.system.WorkerThread.run(WorkerThread.java:559)
> {code}
> (Regardless of the full resolution of the problem, we should definitely
> harden the connector against this kind of issue.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
