jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Jäggi (JIRA) <j...@apache.org>
Subject [jira] [Resolved] (OAK-4845) Regression: DefaultSyncContext does not sync membership to a local group
Date Mon, 03 Oct 2016 07:54:20 GMT

     [ https://issues.apache.org/jira/browse/OAK-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dominique Jäggi resolved OAK-4845.
----------------------------------
    Resolution: Won't Fix

as discussed by phone with [~alexander.klimetschek], this change will be reverted. Separation
between groups (IDP vs local) needs to be maintained in terms of sync. The client needs to
ensure not to rely on pre-existing local groups matching a group in an IDP.

reverted in r1763122.

> Regression: DefaultSyncContext does not sync membership to a local group
> ------------------------------------------------------------------------
>
>                 Key: OAK-4845
>                 URL: https://issues.apache.org/jira/browse/OAK-4845
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: auth-external
>    Affects Versions: 1.5.3, 1.4.7
>            Reporter: Alexander Klimetschek
>            Assignee: Dominique Jäggi
>            Priority: Critical
>             Fix For: 1.6, 1.4.8
>
>         Attachments: OAK-4845-test-lostmembership.patch, OAK-4845.patch, missing-commits-in-tests.patch
>
>
> OAK-4397 introduced a regression: it does not allow syncing to a locally existing group
anymore (that does not belong to another IDP).
> Updating to 1.4.7 now gives "Existing authorizable 'X' is not a group from this IDP 'foo'.",
and the group is not synced and most importantly, memberships for external users are not updated
anymore. Looking at the group in JCR, it does not have a {{rep:externalId}} at all, only a
{{rep:lastSynced}}.
> Code wise, this is because the {{rep:externalId}} is only ever set in {{createGroup()}},
i.e. when the external sync creates that group initially. If the group is already present
locally (but not owned by another IDP!), then it won't use it due to the new {{isSameIDP()}}
check, which will also fail if there is no {{rep:externalId}} property set.
> The use case is that we are defining the group locally as part of our application already
(including ACs etc.) and we want certain external users be added to it, based on some some
of their settings on the external IDP side. FWIW, we don't care for the syncing of properties
for the group itself, just for the memberships.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message