[
https://issues.apache.org/jira/browse/CONNECTORS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802620#comment-13802620
]
Karl Wright commented on CONNECTORS-754:
----------------------------------------
I have an implementation which could conceivably work checked into
branches/CONNECTORS-754. But now I've started to think through the broader
implications of the SharePoint auth model. Basically, instead of one
authority, Claim Space is designed to allow multiple authorities to provide
authorization for one repository. For example, a SharePoint user might provide
native SharePoint groups, while an Active Directory user might provide Active
Directory - linked SharePoint groups. A Facebook user might provide Facebook
groups.
The same user name is not necessarily applicable to all of these; it would be
inappropriate to send a Facebook user to an Active Directory authority, etc.
So what I see here is a broader picture where there several structural changes
to
how authorities work:
(1) Incoming users to the authority service have an attached domain name, and
there can be multiple domain/user pairs in each request. This has been
previous proposed elsewhere; it is time now to make this official.
(2) Each domain selects for N authorities and their prerequisite mappers. So
if a request contains two domains, two entirely different sets of authorities
are fired off as a result: one set associated with one domain, and the other
set with the other domain. Each mapper and authority receives one user name,
as before. (This implies a schema change so that a domain name can be entered
for each authority.)
(3) Each repository connection may use an authority connection from each of
multiple domains. (This too requires a schema change, an additional table, in
order to represent this relationship, and more extensive changes as well
because access tokens from the repository are qualified with the associated
authority right now, and is not clear that the repository will be able to
determine which domain an access token comes from at crawling time.)
More to come...
> 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.5
>
> Attachments: MCPermissionsService-Claims.zip
>
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)
