manifoldcf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phillip Rhodes (JIRA)" <>
Subject [jira] [Commented] (CONNECTORS-1473) Authority Service doesn't return same set of tokens for user at query time as the set used for ingestion, when using Alfresco
Date Sun, 03 Dec 2017 20:16:00 GMT


Phillip Rhodes commented on CONNECTORS-1473:

I'm talking about the allow_token_document field.  In Alfresco I have granted permissions
to a folder for individual discrete users (as opposed to a group), and at ingestion time I
see (correctly, as I understand it) tokens for those individual users.  

"allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
"Alfresco:testuser3", "Alfresco:testuser4"],

But at query time, when sending, say, testuser1, to the authority service, you don't get back
an access token for the *user*, only the groups that user is in.  And so you don't get any
search results even though the user actually has permission to that content.

> Authority Service doesn't return same set of tokens for user at query time as the set
used for ingestion, when using Alfresco
> -----------------------------------------------------------------------------------------------------------------------------
>                 Key: CONNECTORS-1473
>                 URL:
>             Project: ManifoldCF
>          Issue Type: Bug
>          Components: Alfresco webscript connector
>         Environment: Alfresco:
> Installed Schema	6022
> Installed Version	4.2.0 (4576)
> Server Schema	6022
> Server Version	4.2.0 (4576)
> ManifoldCF - built from source using the latest sources about a month ago
> Solr - 6.6.0
>            Reporter: Phillip Rhodes
>            Assignee: Karl Wright
>             Fix For: ManifoldCF 2.9
>         Attachments: CONNECTORS-1473.patch
> Using ManifoldCF to index content from Alfresco into Solr, and using the MCF SearchComponent
to restrict access on the Solr side, I'm seeing the following unusual behavior:
> 1. I have an Alfresco server storing documents.   There are 65 docs in
> the built in "sample" space, which defaults to allowing access to
> everyone.
> 2. With the MCF SearchComponent installed into Solr, if I pass the
> AuthenticatedUserName parameter with any value, I get back all 65
> documents as expected.
> 3. I added another space in Alfresco that only allows access for 4
> specific users... testuser1, testuser2, testuser3, and testuser4. If I
> log into Alfresco as any of those users I can view and/or upload
> content to the space.
> 4. I put 7 documents in that space, and re-indexed with MCF.
> 5. Solr now shows a total of 72 documents for the core in question.
> 6. But, if I pass AuthenticatedUserName=testuser1 with my query, I
> still only see the 65 docs from the other space.
> 7. If I temporarily turn off the MCF SearchComponent in Solr, I can
> see the docs from the "locked down" space.
> I set the various token fields to stored="true" so I can see what is
> getting stored, and here's what I see for one sample document (one
> that isn't being returned with the SearchComponent enabled, but which
> should be).
> "allow_token_document":["Alfresco:testuser1", "Alfresco:testuser2",
> "Alfresco:testuser3", "Alfresco:testuser4"],
> "deny_token_document":["__nosecurity__"],
> "deny_token_parent":["__nosecurity__"],
> "allow_token_share":["__nosecurity__"],
> "allow_token_parent":["__nosecurity__"],
> "deny_token_share":["__nosecurity__"],
> Note that at ingestion time, tokens were created of the form Alfresco:username for the
specific individual users which were granted access to the "secure" folder.
> However, if I make a direct request to the MCF UserACL's endpoint for, say, testuser1,
like this:
> I get back:
> AUTHORIZED:Alfresco+Authority+Connection
> which explains why I can see the documents from the public folder, because they all have
an allow_token_document for Alfresco:GROUP_EVERYONE.  But note that what I don't get back
here is the token for the specific user testuser1, which would match what was stored during

This message was sent by Atlassian JIRA

View raw message