[jira] [Commented] (OAK-7817) oak-doc-railroad-macro should be built in default reactor built
[
https://issues.apache.org/jira/browse/OAK-7817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672362#comment-16672362
]
Tobias Bocanegra commented on OAK-7817:
---
it depends a bit if you just want a mirror or an independent git repository.
jackrabbit-filevault is just a mirror of an svn tree, see
https://www.apache.org/dev/git.html#git-mirrors.
some other projects, like sling or cordova moved completely to github. but I'm
not sure how the process is there. I guess you could also request to create a
new repo in github or as a dual master: https://git.apache.org/ maybe
[~fmeschbe] or [~stevegill] nows more about that process.
in any case, once you know what you want, you need to file a INFRA issue to get
it going.
> oak-doc-railroad-macro should be built in default reactor built
> ---
>
> Key: OAK-7817
> URL: https://issues.apache.org/jira/browse/OAK-7817
> Project: Jackrabbit Oak
> Issue Type: Documentation
> Components: doc
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> {{oak-doc}} is dependent on {{oak-doc-railroad-macro}} but the site
> generation step mentioned in {{oak-doc/README}} have {{mvn site -Pdoc}} which
> wont' build railroad macro module.
> So, on a fresh system (or cleaned .m2 folder) would fail to do {{mvn site
> -Pdoc}}.
> A simple solution (outside of mentioning this in README itself) is to build
> {{oak-doc-railroad-macro}} in default reactor build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6144) ExternalIdentity should have a method indicating if an identity is actually active
[
https://issues.apache.org/jira/browse/OAK-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16029525#comment-16029525
]
Tobias Bocanegra commented on OAK-6144:
---
bq. I tried that, but after adding the @ProviderType annotation to
ExternalIdentity the baseline plugin still fails. Can you explain?
AFAIK, the default is {{@ConsumerType}}. switching to {{@ProviderType}} already
mandates a major version increase.
IMO, we can skip the baseline plugin for this change. it will a bit tricky to
release the next version, though, as the release process must explicitly skip
the plugin. iirc, with {{-Darguments=-Dbaseline.skip=true}}
[~cziegeler] what would you suggest to do here?
> ExternalIdentity should have a method indicating if an identity is actually
> active
> --
>
> Key: OAK-6144
> URL: https://issues.apache.org/jira/browse/OAK-6144
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: auth-external
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
> Attachments: oak-6144-1.patch
>
>
> The interface ExternalIdentityProvider currently offers the method
> getIdentity(ExternalIdentityRef) to resolve a reference to an external
> Identity, but there is no way to tell if the external identity is considered
> active by the identity provider. The ability to resolve the reference doesn't
> mean that the resulting identity may actually be used for authentication or
> authorization.
> If ExternaIIdentity isn't able to express this difference, it's hard to come
> up with a sensible implemenation of e.g.
> SynchronizationMBean#purgeOrphanedUsers(), because the ability to resolve a
> reference to an external identity doesn't mean that the corresponding Oak
> user is still valid.
> A new method ExternalIdentiy#isActive() would allow us to clearly define the
> notion of an "orphaned user".
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6144) ExternalIdentity should have a method indicating if an identity is actually active
[ https://issues.apache.org/jira/browse/OAK-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005884#comment-16005884 ] Tobias Bocanegra commented on OAK-6144: --- +1 LGTM, but I think you need to increase the package version to 2.3.1 in: https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/package-info.java > ExternalIdentity should have a method indicating if an identity is actually > active > -- > > Key: OAK-6144 > URL: https://issues.apache.org/jira/browse/OAK-6144 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > Attachments: oak-6144-1.patch > > > The interface ExternalIdentityProvider currently offers the method > getIdentity(ExternalIdentityRef) to resolve a reference to an external > Identity, but there is no way to tell if the external identity is considered > active by the identity provider. The ability to resolve the reference doesn't > mean that the resulting identity may actually be used for authentication or > authorization. > If ExternaIIdentity isn't able to express this difference, it's hard to come > up with a sensible implemenation of e.g. > SynchronizationMBean#purgeOrphanedUsers(), because the ability to resolve a > reference to an external identity doesn't mean that the corresponding Oak > user is still valid. > A new method ExternalIdentiy#isActive() would allow us to clearly define the > notion of an "orphaned user". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6102) LdapIdentityProvider#getIdentity(ExternalIdentityRef) and LdapIdentityProvider#getUser(String) should behave consistently.
[
https://issues.apache.org/jira/browse/OAK-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982922#comment-15982922
]
Tobias Bocanegra commented on OAK-6102:
---
or {{ExternalIdentity.isActive()}}.
> LdapIdentityProvider#getIdentity(ExternalIdentityRef) and
> LdapIdentityProvider#getUser(String) should behave consistently.
> --
>
> Key: OAK-6102
> URL: https://issues.apache.org/jira/browse/OAK-6102
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.4.15, 1.6.1, 1.0.38, 1.2.25
>Reporter: Manfred Baedke
>Priority: Minor
>
> The method LdapIdentityProvider#getIdentity(ExternalIdentityRef) doesn't use
> the configurable user.extrafilter, while LdapIdentityProvider#getUser(String)
> does. The latter behavior is correct and should also be implemented by
> #getIdentity(ExternalIdentityRef).
> (cc [~anchela], [~tripod])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6102) LdapIdentityProvider#getIdentity(ExternalIdentityRef) and LdapIdentityProvider#getUser(String) should behave consistently.
[
https://issues.apache.org/jira/browse/OAK-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15978984#comment-15978984
]
Tobias Bocanegra commented on OAK-6102:
---
I don't argue that the listOrphanedUsers() is not buggy, but that respecting
the filter to the LdapIdentityProvider #getIdentity() would be wrong. The
filter is used to limit the mapping from user-id to external-id (DN).
However, I agree that if we look at the extra-filter as a condition for
retrieving valid users in the first place, it would probably make sense to
respect it later on when retrieving the identity. But I fear that we will run
into problems later, if we change this now.
maybe it would be better to convey the notion of 'deactivated' identities
instead of deleted ones. i.e. if the Identity had a {{isEnabled()}} property,
that could be respected by the orphaned user handling.
> LdapIdentityProvider#getIdentity(ExternalIdentityRef) and
> LdapIdentityProvider#getUser(String) should behave consistently.
> --
>
> Key: OAK-6102
> URL: https://issues.apache.org/jira/browse/OAK-6102
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.4.15, 1.6.1, 1.0.38, 1.2.25
>Reporter: Manfred Baedke
>Priority: Minor
>
> The method LdapIdentityProvider#getIdentity(ExternalIdentityRef) doesn't use
> the configurable user.extrafilter, while LdapIdentityProvider#getUser(String)
> does. The latter behavior is correct and should also be implemented by
> #getIdentity(ExternalIdentityRef).
> (cc [~anchela], [~tripod])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6102) LdapIdentityProvider#getIdentity(ExternalIdentityRef) and LdapIdentityProvider#getUser(String) should behave consistently.
[
https://issues.apache.org/jira/browse/OAK-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976258#comment-15976258
]
Tobias Bocanegra commented on OAK-6102:
---
bq. ... are you saying that this isn't a bug but working as expected?
Just from looking at the code, I don't understand why the {{getIdentity()}}
should respect the filter. [~baedke] what is the use case here?
> LdapIdentityProvider#getIdentity(ExternalIdentityRef) and
> LdapIdentityProvider#getUser(String) should behave consistently.
> --
>
> Key: OAK-6102
> URL: https://issues.apache.org/jira/browse/OAK-6102
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.4.15, 1.6.1, 1.0.38, 1.2.25
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Minor
>
> The method LdapIdentityProvider#getIdentity(ExternalIdentityRef) doesn't use
> the configurable user.extrafilter, while LdapIdentityProvider#getUser(String)
> does. The latter behavior is correct and should also be implemented by
> #getIdentity(ExternalIdentityRef).
> (cc [~anchela], [~tripod])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6102) LdapIdentityProvider#getIdentity(ExternalIdentityRef) and LdapIdentityProvider#getUser(String) should behave consistently.
[
https://issues.apache.org/jira/browse/OAK-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975870#comment-15975870
]
Tobias Bocanegra edited comment on OAK-6102 at 4/20/17 1:12 AM:
the extra filter is used in
{{listUsers()}} / {{listGroups()}} via the internal {{getEntryIterator()}}
and in
{{getUser()}} / {{getGroup()}} via {{getEntry()}} via {{getSearchFilter()}}
since those methods use the userId or groupId to find the ldap entry based on
the filters.
but the {{LdapIdentityProvider#getIdentity(ExternalIdentityRef)}} uses the
{{ExternalIdentityRef#getId}} which is the DN for the LDAP case. So no
filtering applies here.
was (Author: tripod):
the extra filter is used in
{{listUsers()}}
{{listGroups()}}
via the internal {{getEntryIterator()}}
and in
{{getUser()}} / {{getGroup()}} via {{getEntry()}} via {{getSearchFilter()}}
since those methods use the userId or groupId to find the ldap entry based on
the filters.
but the {{LdapIdentityProvider#getIdentity(ExternalIdentityRef)}} uses the
{{ExternalIdentityRef#getId}} which is the DN for the LDAP case. So no
filtering applies here.
> LdapIdentityProvider#getIdentity(ExternalIdentityRef) and
> LdapIdentityProvider#getUser(String) should behave consistently.
> --
>
> Key: OAK-6102
> URL: https://issues.apache.org/jira/browse/OAK-6102
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.4.15, 1.6.1, 1.0.38, 1.2.25
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Minor
>
> The method LdapIdentityProvider#getIdentity(ExternalIdentityRef) doesn't use
> the configurable user.extrafilter, while LdapIdentityProvider#getUser(String)
> does. The latter behavior is correct and should also be implemented by
> #getIdentity(ExternalIdentityRef).
> (cc [~anchela], [~tripod])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6102) LdapIdentityProvider#getIdentity(ExternalIdentityRef) and LdapIdentityProvider#getUser(String) should behave consistently.
[
https://issues.apache.org/jira/browse/OAK-6102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975870#comment-15975870
]
Tobias Bocanegra commented on OAK-6102:
---
the extra filter is used in
{{listUsers()}}
{{listGroups()}}
via the internal {{getEntryIterator()}}
and in
{{getUser()}} / {{getGroup()}} via {{getEntry()}} via {{getSearchFilter()}}
since those methods use the userId or groupId to find the ldap entry based on
the filters.
but the {{LdapIdentityProvider#getIdentity(ExternalIdentityRef)}} uses the
{{ExternalIdentityRef#getId}} which is the DN for the LDAP case. So no
filtering applies here.
> LdapIdentityProvider#getIdentity(ExternalIdentityRef) and
> LdapIdentityProvider#getUser(String) should behave consistently.
> --
>
> Key: OAK-6102
> URL: https://issues.apache.org/jira/browse/OAK-6102
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.4.15, 1.6.1, 1.0.38, 1.2.25
>Reporter: Manfred Baedke
>Assignee: Manfred Baedke
>Priority: Minor
>
> The method LdapIdentityProvider#getIdentity(ExternalIdentityRef) doesn't use
> the configurable user.extrafilter, while LdapIdentityProvider#getUser(String)
> does. The latter behavior is correct and should also be implemented by
> #getIdentity(ExternalIdentityRef).
> (cc [~anchela], [~tripod])
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875922#comment-15875922
]
Tobias Bocanegra commented on OAK-5229:
---
but isn't this a backward incompatible change? especially, all the applications
that remove versioning and/or access control by removing the mixin would fail.
I think the risk of braking many application by changing this is behavior is
huge.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875130#comment-15875130
]
Tobias Bocanegra commented on OAK-5229:
---
uh... I don't think this is a good behavior for {{mix:Versionable}} and
{{rep:AccessControllable}}. Since those are internal properties that only make
sense in combination with the respective type. Especially the reference
properties of {{mix:Versionable}} should be removed, since they might now point
to a node in the version store that no longer exists.
so rather than fixing the test, I would add those exceptions to the code that
purges the properties. otherwise there will be plenty of backward compatibility
issues.
[~anchela] wdyt?
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch, OAK-5229-v5.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866973#comment-15866973
]
Tobias Bocanegra commented on OAK-5229:
---
I agree, so the following happens:
- if an item (property or node) is no longer allowed with the new primary type,
then a ConstraintViolationException is thrown.
- no items get removed
so in order to change the primary type to a more restrictive one, the
application needs to re-import the node, or figure out which items to remove
before calling setPrimaryType.
(in case of vault, we would "catch" the ConstraintViolation exception and
re-import the node, or throw an error, based on the import mode)
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864719#comment-15864719
]
Tobias Bocanegra commented on OAK-5229:
---
bq. E.g. removing a mix:referenceable on a nt:unstructured would not remove
the jcr:uuid property.
I'm not sure about this one :-) since it is a "system" property, it should not
show up when you make the node un-referenceable.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863061#comment-15863061
]
Tobias Bocanegra commented on OAK-5229:
---
bq. an alternative to 'cleanup' was also: abort the setPrimaryType... i don't
have a strong preference but as far as i remember jackrabbit 2.x did cleanup...
IIRC, it depends on the new primary type. e.g. if you change a nt:folder to
nt:unstructured, the jcr:created etc should stay. only if the autocreated
mandatory properties are no longer valid, they should be removed.
afaics the current proposal:
- prevents corrupting the repository with invalid primary types
- does a best-effort check on the transient space
so should be good :-)
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch,
> OAK-5229-v3.patch, OAK-5229-v4.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15847241#comment-15847241
]
Tobias Bocanegra commented on OAK-5229:
---
bq. bq. I think the method should fail immediately, and not only after commit:
bq. the validation hook runs at commit time, so that's when you'll get the error
but adding a mixin also checks immediately, and so should changing the primary
type; as mandated by the JCR spec.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.8, 1.6.1
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch, OAK-5229-v2.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1583#comment-1583
]
Tobias Bocanegra commented on OAK-5229:
---
bq. I had to tweak the provided test to log out the admin session, otherwise
the bad node would prevent the anonymous session from being created.
why? so this would still corrupt the system if an admin session changes the
primary type?
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.6
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15839996#comment-15839996
]
Tobias Bocanegra commented on OAK-5229:
---
I think the method should fail immediately, and not only after commit:
{noformat}
* @throws ConstraintViolationException if the specified primary node type
* creates a type conflict and this
implementation performs this validation
* immediately.
{noformat}
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Alex Parvulescu
>Priority: Critical
> Fix For: 1.6
>
> Attachments: OAK-5229.patch, OAK-5229-tests.patch
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5210) Ability to resolve principal name from ExternalIdentityRef without IDP roundtrip
[
https://issues.apache.org/jira/browse/OAK-5210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823337#comment-15823337
]
Tobias Bocanegra commented on OAK-5210:
---
+1 patch looks good to me.
> Ability to resolve principal name from ExternalIdentityRef without IDP
> roundtrip
>
>
> Key: OAK-5210
> URL: https://issues.apache.org/jira/browse/OAK-5210
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Attachments: OAK-5210-initialdraft.patch
>
>
> Currently the only way to reliably determine the principal name for a given
> external identity is by calling {{ExternalIdentity.getPrincipalName()}}. This
> also means that there is currently no way to resolve the principal name from
> a given {{ExternalIdentityRef}}, without calling
> {{ExternalIdentityProvider.getIdentity(ExternalIdentityRef)}}.
> In the default sync mode a given identity-ref will always be resolved to the
> associated identity once a given identity is up for (re)sync and thus the
> identity resolution is part of the synchronization. On the other hand the
> partial sync as provided by the {{DynamicSyncContext}} doesn't require the
> resolution of group identities but only needs to be able to obtain the
> principal name, which is needed to proper populate the subject upon
> repository login (and for permission setup for those group principals). In
> this setup it would be preferrable if the principal name could be resolved
> from the {{ExternalIdentityRef}} without the intermediate identity resolution.
> This aim of this issue is to discuss the different options on how to achieve
> this improvement in a generic way that doesn't make any assumptions regarding
> the relationship between {{ExternalIdentity.getId}},
> {{ExternalIdentity.getPrincipalName}} and {{ExternalIdentityRef.getId}}.
> See also OAK-4930 and OAK-5200 for additional information.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818305#comment-15818305
]
Tobias Bocanegra commented on OAK-5229:
---
another easy way to cause havoc:
{noformat}
curl -u admin:admin -F"jcr:primaryType=nt:resource" http://localhost:4502/libs
{noformat}
fortunately, the {{setPrimaryType()}} doesn't work on the root node
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818068#comment-15818068
]
Tobias Bocanegra edited comment on OAK-5229 at 1/11/17 11:33 AM:
-
The problem is, that you can change the nodetype in such a way, that the
repository will be broken in that subtree. If you import packages via vault,
you can end up in this state. I think there is a possibility that this can
happen.
Is it really so hard to verify this? the logic already exists when altering
mixin types.
I set it to critical, because you can render the repository unusable with a
simple {{setPrimaryType()}} call.
was (Author: tripod):
The problem is, that you can change the nodetype in such a way, that the
repository will be broken in that subtree. If you import packages via vault,
you can end up in this state. I think there is a possibility that this can
happen.
Is it really so hard to verify this? the logic already exists when altering
mixin types.
I set it to critical, because you can render the repository unusable with a
simple {{setNodeType()}} call.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818068#comment-15818068
]
Tobias Bocanegra commented on OAK-5229:
---
The problem is, that you can change the nodetype in such a way, that the
repository will be broken in that subtree. If you import packages via vault,
you can end up in this state. I think there is a possibility that this can
happen.
Is it really so hard to verify this? the logic already exists when altering
mixin types.
I set it to critical, because you can render the repository unusable with a
simple {{setNodeType()}} call.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-5229:
--
Fix Version/s: 1.5.16
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Priority: Critical
> Fix For: 1.5.16
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5249) DefaultAuthorizableActionProvider should use @Modified to react to config changes
Tobias Bocanegra created OAK-5249:
-
Summary: DefaultAuthorizableActionProvider should use @Modified to
react to config changes
Key: OAK-5249
URL: https://issues.apache.org/jira/browse/OAK-5249
Project: Jackrabbit Oak
Issue Type: Improvement
Components: security
Affects Versions: 1.5.14
Reporter: Tobias Bocanegra
The DefaultAuthorizableActionProvider [0] doesn't handle the @Modified
component description, causing entire OAK to restart when the config changes.
suggested change:
{code}
@Activate
private void activate(Map properties) {
this.modified(properties);
}
@Modified
private void modified(Map properties) {
config = ConfigurationParameters.of(properties);
enabledActions = config.getConfigValue(ENABLED_ACTIONS,
DEFAULT_ACTIONS);
}
{code}
[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-5229:
--
Description:
1. Assume the following:
{noformat}
/testNode [nt:unstructured]
/unstructured_child [nt:unstructured]
{noformat}
2. setting "/testNode".setPrimaryType("nt:folder")
3. save the session.
Altering the primary type works, thus leaving the repository in an inconsistent
state.
Interestingly, subsequent calls to
"/testNiode/unstructured_child".setProperty() will fail:
{noformat}
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
/test_node[[nt:folder]]: No matching definition found for child node
unstructured_child with effective type [nt:unstructured]
{noformat}
was:
1. Assume the following:
{noformat}
/testNode [nt:unstructured]
/unstructured_child [nt:unstructured]
{noformat}
2. setting "/testNode".setPrimaryType("nt:folder")
the above works, leaving the repository in an inconsistent state.
subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
{noformat}
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
/test_node[[nt:folder]]: No matching definition found for child node
unstructured_child with effective type [nt:unstructured]
{noformat}
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Priority: Critical
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15727424#comment-15727424
]
Tobias Bocanegra commented on OAK-5229:
---
btw: the javadoc states:
{noformat}
* @throws ConstraintViolationException if the specified primary node type
* creates a type conflict and this
implementation performs this validation
* immediately.
{noformat}
It would be convenient if the validation is done immediately, so that the
application can test if changing the nodetype is possible.
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Priority: Critical
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> the above works, leaving the repository in an inconsistent state.
> subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15727414#comment-15727414
]
Tobias Bocanegra commented on OAK-5229:
---
added "ignored" test in r1773002:
https://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/RepositoryTest.java?r1=1773002&r2=1773001&pathrev=1773002
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> the above works, leaving the repository in an inconsistent state.
> subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-5229:
--
Priority: Critical (was: Major)
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>Priority: Critical
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> the above works, leaving the repository in an inconsistent state.
> subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15727400#comment-15727400
]
Tobias Bocanegra commented on OAK-5229:
---
{code}
@Test
public void setPrimaryTypeFails() throws RepositoryException {
Node testNode = getNode(TEST_PATH);
assertEquals("nt:unstructured",
testNode.getPrimaryNodeType().getName());
assertEquals("nt:unstructured",
testNode.getProperty("jcr:primaryType").getString());
// create subnode that would not be allowed with nt:folder
testNode.addNode("unstructured_child", NodeType.NT_UNSTRUCTURED);
getAdminSession().save();
testNode.setPrimaryType("nt:folder");
try {
getAdminSession().save();
/*1*/ fail("Changing the primary type to nt:folder should fail.");
} catch (RepositoryException e) {
// ok
}
Session session2 = createAnonymousSession();
try {
testNode = session2.getNode(TEST_PATH);
/*2*/ assertEquals("nt:unstructured",
testNode.getPrimaryNodeType().getName());
assertEquals("nt:unstructured",
testNode.getProperty("jcr:primaryType").getString());
} finally {
session2.logout();
}
getAdminSession().getNode(TEST_PATH +
"/unstructured_child").setProperty("test", "value");
/*3*/ getAdminSession().save();
}
{code}
Sample test:
1. saving the changed primary type should fail.
2. if the check for (1) is disabled, then (2) fails. and nodetype indeed is now
nt:folder
3. if the check for (1) and (2) is disabled, then (3) fails with exception
mentioned above
> Using Node.setPrimaryType() should fail if non-matching childnodes
> --
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.14
>Reporter: Tobias Bocanegra
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> the above works, leaving the repository in an inconsistent state.
> subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-5229) Using Node.setPrimaryType() should fail if non-matching childnodes
Tobias Bocanegra created OAK-5229:
-
Summary: Using Node.setPrimaryType() should fail if non-matching
childnodes
Key: OAK-5229
URL: https://issues.apache.org/jira/browse/OAK-5229
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.14
Reporter: Tobias Bocanegra
1. Assume the following:
{noformat}
/testNode [nt:unstructured]
/unstructured_child [nt:unstructured]
{noformat}
2. setting "/testNode".setPrimaryType("nt:folder")
the above works, leaving the repository in an inconsistent state.
subsequent calls to "/testNiode/unstructured_child".setProperty() will fail:
{noformat}
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
/test_node[[nt:folder]]: No matching definition found for child node
unstructured_child with effective type [nt:unstructured]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15610169#comment-15610169
]
Tobias Bocanegra commented on OAK-4857:
---
going back to the original problem, if we would just allow u3000 and u00A0 as
whitespace, it would solve many problems so far. of course the application can
escape/replace those.
btw: does jackrabbits webdav implementation automatically escape all those
chars?
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532244#comment-15532244
]
Tobias Bocanegra commented on OAK-4857:
---
I think the easiest is to allow all spec compliant characters. no exceptions
based on case-by-case. IMO it is the responsibility of the application layer to
restrict the range if really desired. AFAICS, there is not technical reason to
limit the range on the repository level.
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing some of them (the non breaking spaces) at the _beginning
> or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15529074#comment-15529074
]
Tobias Bocanegra commented on OAK-4857:
---
I frankly don't understand why we should limit the range of allowed characters
beyond the illegal jcr ones.
it's like a filesystem that is enforcing 8.3 notation :-)
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing them at the _beginning or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528875#comment-15528875
]
Tobias Bocanegra commented on OAK-4857:
---
use case is storing files in JCR and retain thir filename. this is currently
not possible, if the filenames contains for example a u3000.
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing them at the _beginning or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4857) Support space chars common in CJK inside node names
[
https://issues.apache.org/jira/browse/OAK-4857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528123#comment-15528123
]
Tobias Bocanegra commented on OAK-4857:
---
+1 for allowing all 'Z' spaces. the current restriction is a blocker for many
Chinese, Japanese and Korean users.
> Support space chars common in CJK inside node names
> ---
>
> Key: OAK-4857
> URL: https://issues.apache.org/jira/browse/OAK-4857
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.4.7, 1.5.10
>Reporter: Alexander Klimetschek
> Attachments: OAK-4857-tests.patch
>
>
> Oak (like Jackrabbit) does not allow spaces commonly used in CJK like
> {{u3000}} (ideographic space) or {{u00A0}} (no-break space) _inside_ a node
> name, while allowing them at the _beginning or end_.
> They should be supported for better globalization readiness, and filesystems
> allow them, making common filesystem to JCR mappings unnecessarily hard.
> Escaping would be an option for applications, but there is currently no
> utility method for it
> ([Text.escapeIllegalJcrChars|https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String)]
> will not escape these spaces), nor is it documented for applications how to
> do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4825) Support disabling of users instead of removal in DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505286#comment-15505286
]
Tobias Bocanegra commented on OAK-4825:
---
I like the idea:
{noformat}
/**
* Controls the behavior for users that no longer exist on the external
provider. The default is to delete the repository users
* if they no longer exist on the external provider. If set to true, they will
be disabled instead, and re-enabled once they appear
* again.
*/
boolean disableMissingUsers;
{noformat}
we could add a bit more flexibility and add a auto-purge time instead of just a
flag.
eg:
{noformat}
/**
* Timespan (human notation) after which an externally deleted user is purged.
A user that is no longer available on the external
* provider will linger in the repository as a disabled user until this
expiration time has passed, after which it will be deleted.
* Use 0 to delete immediately, -1 to never delete.
*
* Example: "30d" will invalidate a no longer existing user and delete it after
30 days"
*/
String userLingerTime;
{noformat}
> Support disabling of users instead of removal in DefaultSyncHandler
> ---
>
> Key: OAK-4825
> URL: https://issues.apache.org/jira/browse/OAK-4825
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
>
> The DefaultSyncHandler by default will remove (local) users when they are no
> longer active in the external system aka no longer provided by the
> ExternalIdentityProvider. It would be useful to have an option to _disable_
> users instead of removing them completely.
> This is good for use cases that need to keep the user's data around in the
> JCR and can't just delete it. Also, we have seen cases where the user is only
> temporarily removed from the external identity system (e.g. accidentally
> removed from group that maps them to the JCR system and quickly added back),
> where a full removal can do harm.
> (Note: There is an [option in the SyncContext
> interface|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/SyncContext.java#L38]
> to suppress purging, and the JMX sync commands such as
> [purgeOrphanedUsers()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/jmx/Delegatee.java#L256]
> "use" it. However, the JCR users look like "valid" users then locally. Even
> if the authentication is done completely through the IDP and will fail
> properly for these missing users, it can be difficult for other uses like
> administration, monitoring, other application code to detect that such a user
> is not active anymore.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321473#comment-15321473
]
Tobias Bocanegra commented on OAK-3508:
---
also fixed in 1.2: r1747456
[~anchela] I also wanted to backport the tests from OAK-4417 but they had too
many dependencies to code changes. so I couldn't.
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.23, 1.2.16
>
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3508:
--
Fix Version/s: 1.2.16
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.23, 1.2.16
>
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4087) Replace Sync of configured AutoMembership by Dynamic Principal Generation
[
https://issues.apache.org/jira/browse/OAK-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308756#comment-15308756
]
Tobias Bocanegra commented on OAK-4087:
---
+1 looks good to me. thanks
> Replace Sync of configured AutoMembership by Dynamic Principal Generation
> -
>
> Key: OAK-4087
> URL: https://issues.apache.org/jira/browse/OAK-4087
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Labels: performance
> Attachments: OAK-4087.patch, OAK-4087_documentation.patch
>
>
> the {{DefaultSyncConfig}} comes with a configuration option
> {{PARAM_USER_AUTO_MEMBERSHIP}} indicating the set of groups a given external
> user must always become member of upon sync into the repository.
> this results in groups containing almost all users in the system (at least
> those synchronized form the external IDP). while this behavior is straight
> forward (and corresponds to the behavior in the previous crx version), it
> wouldn't be necessary from a repository point of view as a given {{Subject}}
> can be populated from different principal sources and dealing with this kind
> of dynamic-auto-membership was a typical use-case.
> what does that mean:
> instead of performing the automembership on the user management, the external
> authentication setup could come with an auto-membership {{PrincipalProvider}}
> implementation that would expose the desired group membership for all
> external principals (assuming that they were identified as such).
> [~tripod], do you remember if that was ever an option while building the
> {{oak-auth-external}} module? if not, could that be worth a second thought
> also in the light of OAK-3933?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4379) Batch mode for SyncMBeanImpl
[
https://issues.apache.org/jira/browse/OAK-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15291665#comment-15291665
]
Tobias Bocanegra commented on OAK-4379:
---
good idea. maybe the batch size can be specified?
> Batch mode for SyncMBeanImpl
>
>
> Key: OAK-4379
> URL: https://issues.apache.org/jira/browse/OAK-4379
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
> Labels: performance
>
> the {{SyncMBeanImpl}} currently calls {{Session.save()}} for every single
> sync, which IMO make the synchronization methods extra expensive.
> IMHO we should consider introducing a batch mode that reduces the number of
> save calls. the drawback of this was that the complete set of sync-calls
> withing a given batch would succeed or fail. in case of failure the
> 'original' sync-result would need to be replaced by one with operation status
> 'ERR'.
> now that we have the basis for running benchmarks for the {{SyncMBeanImpl}},
> we should be able to verify if this proposal actually has a positive impact
> (though benchmark results from OAK-4119 and OAK-4120 seem to indicate that
> this is the case).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4101) Consider separate external (group) principal management
[
https://issues.apache.org/jira/browse/OAK-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1528#comment-1528
]
Tobias Bocanegra commented on OAK-4101:
---
as far as I can tell, this is ok. I created a temporary pull request with my
comments, mostly minor stuff:
https://github.com/apache/jackrabbit-oak/pull/52
- In general, the {{...impl.principal.External*}} code could benefit from a bit
more commenting :-)
- I ran the tests and they all pass.
- I didn't test it in a real life setup.
> Consider separate external (group) principal management
> ---
>
> Key: OAK-4101
> URL: https://issues.apache.org/jira/browse/OAK-4101
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Attachments: OAK-4101.patch, OAK-4101_test.patch
>
>
> Given the fact that user management is delegated to an external IDP provider,
> we might reconsider the current approach that attempts to synchronize user
> and particularly group and their membership into the repository.
> What would left with the repository is a dedicated {{PrincipalProvider}} for
> external groups (and maybe even users at a later stage), making sure that
> - the {{Subject}} is properly populated with {{Principal}} s upon login
> - access control can still be properly setup and managed in the repository
> for the principals defined in the external IDP.
> the consequences would be:
> - external groups (and potentially) users would no longer made available to
> the default user management implementation. alternatively: make them
> available as read-only stub i.e. group-membership as defined by the IDP could
> no longer be changed/manipulated in the reposiotry.
> - they are however exposed as principals to assert proper authentication +
> authorization. Note: any UI that properly reflects the fact that access
> control is being edited for principals (and not for users/groups) would not
> be affected at all; others might need to be adjusted to additionally support
> ac management based on the {{PrincipalManager}}
> will try to come up with a POC as soon as I find some time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4363) SyncMBeanImpl: result lacks 'uid' if error messages has been created from ExternalIdentityRef
[
https://issues.apache.org/jira/browse/OAK-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280484#comment-15280484
]
Tobias Bocanegra commented on OAK-4363:
---
I can't remember. maybe an oversight.
> SyncMBeanImpl: result lacks 'uid' if error messages has been created from
> ExternalIdentityRef
> -
>
> Key: OAK-4363
> URL: https://issues.apache.org/jira/browse/OAK-4363
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Priority: Minor
>
> while writing tests for the SyncMBeanImpl I noticed the following method in
> the {{Delegatee}} that writes a sync-result for an error based on an
> {{ExternalIdentityRef}} but sets the 'uid' to empty string:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:\"\",eid:%s,msg:%s}",
> eid, msg);
> list.add(jsonStr);
> }
> {code}
> so, I was wondering why the 'uid' is not retrieved from the
> {{ExternalIdentityRef}} object passed to the method. Something like:
> {code}
> private static void append(@Nonnull List list, @Nonnull
> ExternalIdentityRef idRef, @Nonnull Exception e) {
> String uid = JsonUtil.getJsonString(idRef.getId());
> String eid = JsonUtil.getJsonString(idRef.getString());
> String msg = JsonUtil.getJsonString(e.toString());
> String jsonStr = String.format("{op:\"ERR\",uid:%s,eid:%s,msg:%s}",
> uid, eid, msg);
> list.add(jsonStr);
> }
> {code}
> [~tripod], was there a particular reason for setting 'uid' to empty string?
> or in other words: what was the drawback of setting the uid as exposed by
> {{ExternalIdentityRef.getID()}}?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260834#comment-15260834
]
Tobias Bocanegra edited comment on OAK-4268 at 4/27/16 8:02 PM:
I think there was not much thought put into defining when the identity could be
null.
I would really change the annotation. since the exact case when the identity
can be null was never explained, it doesn't really change the contract if we
make it stricter (if it would be the other ways around, i.e. allowing null all
of a sudden, it would be worse, and I wouldn't change it).
was (Author: tripod):
I think there was not much though put into when the identity could be null. I
would change the annotation. since the exact case when the identity can be null
was never explained, doesn't change the contract if we make it stricter (if it
would be the other ways around, i.e. allowing null all of a sudden, it would be
worse, and I wouldn't change it).
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15260834#comment-15260834
]
Tobias Bocanegra commented on OAK-4268:
---
I think there was not much though put into when the identity could be null. I
would change the annotation. since the exact case when the identity can be null
was never explained, doesn't change the contract if we make it stricter (if it
would be the other ways around, i.e. allowing null all of a sudden, it would be
worse, and I wouldn't change it).
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-1410) Allow automatic propagation of oak-whiteboard when adding security manager
[ https://issues.apache.org/jira/browse/OAK-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved OAK-1410. --- Resolution: Won't Fix > Allow automatic propagation of oak-whiteboard when adding security manager > -- > > Key: OAK-1410 > URL: https://issues.apache.org/jira/browse/OAK-1410 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4048) [regression] SyncHandler.listIdentities() returns all users, not only external ones
[
https://issues.apache.org/jira/browse/OAK-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-4048.
---
Resolution: Fixed
Fix Version/s: 1.6
fixed in r1740879
> [regression] SyncHandler.listIdentities() returns all users, not only
> external ones
> ---
>
> Key: OAK-4048
> URL: https://issues.apache.org/jira/browse/OAK-4048
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: Alexander Klimetschek
>Assignee: Tobias Bocanegra
> Fix For: 1.6
>
> Attachments: OAK-4048.patch
>
>
> OAK-3508 accidentally introduced a regression in
> https://github.com/apache/jackrabbit-oak/commit/cc78f6fdd122d1c9f200b43fc2b9536518ea996b#diff-490ff25c104d019ee25f92b2b8bdbabd
> If {{getIdentityRef(auth)}} returns null, {{createSyncedIdentity}} needs to
> return null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-4268:
--
Assignee: angela (was: Tobias Bocanegra)
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4268) Clarify API contract for SyncResult.getIdentity
[
https://issues.apache.org/jira/browse/OAK-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252261#comment-15252261
]
Tobias Bocanegra commented on OAK-4268:
---
I would change it to NONULL:
{noformat}
/**
* The synchronized identity.
* @return the identity
*/
@Nonnull
SyncedIdentity getIdentity();
{noformat}
> Clarify API contract for SyncResult.getIdentity
> ---
>
> Key: OAK-4268
> URL: https://issues.apache.org/jira/browse/OAK-4268
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
>
> [~tripod], I would appreciate if you could add some clarifying javadoc to
> {{SyncResult.getIdentity}} stating what the nature of the identity is
> expected to be for various status and what it means if the identity is
> {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3626) Provide bind credentials callback
[
https://issues.apache.org/jira/browse/OAK-3626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252229#comment-15252229
]
Tobias Bocanegra commented on OAK-3626:
---
The idea was to decouple the problem of providing the bind password from the
(osgi) configuration, so that the ldap IDP can also work securely w/o osgi.
the issue here at had is to create a mechanism so that the credentials can be
provided from the outside. maybe using a {{LdapBindPasswordProvider}} setting
the the config. And have a default implementation using the crypto support that
is then set in the activate method.
> Provide bind credentials callback
> -
>
> Key: OAK-3626
> URL: https://issues.apache.org/jira/browse/OAK-3626
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: auth-ldap
>Reporter: Tobias Bocanegra
>
> The ldap identity provider reads the admin bind credentials from the given
> config which might originate from a un-encrypted source (eg. osgi config).
> in order to facilitate secure provisioning of the bind credentials, the ldap
> idp should offer some sort of credentials provider callback.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4222) Cleanup ExternalLoginModuleTest
[
https://issues.apache.org/jira/browse/OAK-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250362#comment-15250362
]
Tobias Bocanegra commented on OAK-4222:
---
...but I would keep the {{options.clear()}} in the final blocks in order to be
consistent with the other tests that extend from
{{ExternalLoginModuleTestBase}}. For some reason I needed this, maybe a raise
condition during init.
> Cleanup ExternalLoginModuleTest
> ---
>
> Key: OAK-4222
> URL: https://issues.apache.org/jira/browse/OAK-4222
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-4222.patch
>
>
> While looking at the tests present in oak-auth-external I found the
> {{ExternalLoginModuleTest}} keeping it's own protected {{options}} map hiding
> the {{options}} defined and populated in the setup of the base-class.
> Not sure what this was intended to be used for but the fact that the options
> get cleared in the finally-section of some of the test-cases looks quite
> strange to me.
> [~tripod], I would appreciate if you review the attached patch and let me
> know if you think the proposed cleanup breaks the very intention of your
> test-cases. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4222) Cleanup ExternalLoginModuleTest
[
https://issues.apache.org/jira/browse/OAK-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250346#comment-15250346
]
Tobias Bocanegra commented on OAK-4222:
---
+1 to remove the {{options}}. probably copy-past leftover. thanks!
> Cleanup ExternalLoginModuleTest
> ---
>
> Key: OAK-4222
> URL: https://issues.apache.org/jira/browse/OAK-4222
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-4222.patch
>
>
> While looking at the tests present in oak-auth-external I found the
> {{ExternalLoginModuleTest}} keeping it's own protected {{options}} map hiding
> the {{options}} defined and populated in the setup of the base-class.
> Not sure what this was intended to be used for but the fact that the options
> get cleared in the finally-section of some of the test-cases looks quite
> strange to me.
> [~tripod], I would appreciate if you review the attached patch and let me
> know if you think the proposed cleanup breaks the very intention of your
> test-cases. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4224) DefaultSyncContext.sync(ExternalIdentity) should verify IDP
[
https://issues.apache.org/jira/browse/OAK-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250293#comment-15250293
]
Tobias Bocanegra commented on OAK-4224:
---
I think we should keep the identity in the sync result the same as was put into
the sync call. but set the status to FOREIGN.
I think that the {{SyncResult.getIdentity()}} should never be null. this
simplifies result processing, in cases where the user deals with a list of
results.
> DefaultSyncContext.sync(ExternalIdentity) should verify IDP
> ---
>
> Key: OAK-4224
> URL: https://issues.apache.org/jira/browse/OAK-4224
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-4224.patch, OAK-4224_2.patch
>
>
> while writing more test for {{DefaultSyncContext}} i realized that the
> implementation of {{sync(ExternalIdentity)}} doesn't verify that the given
> external identity belongs to the same IDP than the one associated with the
> context instance.
> IMHO this would be needed and useful particularly when multiple IDPs are
> combined. also, the {{DefaultSyncContext}} is a public exposed class, I
> would prefer if it would guard against mixing up sync of external identities
> from different sources.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4048) [regression] SyncHandler.listIdentities() returns all users, not only external ones
[
https://issues.apache.org/jira/browse/OAK-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246285#comment-15246285
]
Tobias Bocanegra edited comment on OAK-4048 at 4/18/16 6:39 PM:
You are right. There was a change in logic in {{createSyncedIdentity}} that no
longer returns null for null refs. {{listIdentities()}} needs to check for it
now. sorry for the confusion.
was (Author: tripod):
You are right. There was a change in logic in {{createSyncedIdentity}} that no
longer returns null for null refs. List identity needs to check for it now.
sorry for the confusion.
> [regression] SyncHandler.listIdentities() returns all users, not only
> external ones
> ---
>
> Key: OAK-4048
> URL: https://issues.apache.org/jira/browse/OAK-4048
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: Alexander Klimetschek
>Assignee: Tobias Bocanegra
> Attachments: OAK-4048.patch
>
>
> OAK-3508 accidentally introduced a regression in
> https://github.com/apache/jackrabbit-oak/commit/cc78f6fdd122d1c9f200b43fc2b9536518ea996b#diff-490ff25c104d019ee25f92b2b8bdbabd
> If {{getIdentityRef(auth)}} returns null, {{createSyncedIdentity}} needs to
> return null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4048) [regression] SyncHandler.listIdentities() returns all users, not only external ones
[
https://issues.apache.org/jira/browse/OAK-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246285#comment-15246285
]
Tobias Bocanegra commented on OAK-4048:
---
You are right. There was a change in logic in {{createSyncedIdentity}} that no
longer returns null for null refs. List identity needs to check for it now.
sorry for the confusion.
> [regression] SyncHandler.listIdentities() returns all users, not only
> external ones
> ---
>
> Key: OAK-4048
> URL: https://issues.apache.org/jira/browse/OAK-4048
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: Alexander Klimetschek
>Assignee: Tobias Bocanegra
> Attachments: OAK-4048.patch
>
>
> OAK-3508 accidentally introduced a regression in
> https://github.com/apache/jackrabbit-oak/commit/cc78f6fdd122d1c9f200b43fc2b9536518ea996b#diff-490ff25c104d019ee25f92b2b8bdbabd
> If {{getIdentityRef(auth)}} returns null, {{createSyncedIdentity}} needs to
> return null.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4119) Improvements Take 1
[
https://issues.apache.org/jira/browse/OAK-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15198499#comment-15198499
]
Tobias Bocanegra commented on OAK-4119:
---
the patch is too complex to understand if it's correct. if that is implemented
what is described above and all tests pass, then it's ok.
some minor details:
GroupImpl.updateMembers()
- the check for isEveryone() can be outside of the id-loop
MemberReferenceIterator:
- typo: hasProcessedRefeference
> Improvements Take 1
> ---
>
> Key: OAK-4119
> URL: https://issues.apache.org/jira/browse/OAK-4119
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
> Attachments: AddMemberTest_20160314_152515.csv,
> AddMemberTest_with_batch_20160315_150518.csv,
> AddMembersTest_besteffort_20160314_163025.csv,
> IsDeclaredMemberTest_notNested_profiling_20160314_172728.csv,
> IsMemberTest_nested_profiling_20160315_134252.csv,
> IsMemberTest_notNested_profiling_20160315_115809.csv,
> MemberDeclaredMemberOf_nested_profiling_20160314_111037.csv,
> MemberDeclaredMemberOf_notNested_profiling_20160314_103003.csv,
> MemberIsDeclaredMember_notNested_profiling_20160314_115026.csv,
> MemberIsMember_nested_profiling_20160314_142612.csv,
> MemberIsMember_notNested_profiling_20160314_123150.csv,
> MemberMemberOf_nested_profiling_20160314_085505.csv,
> MemberMemberOf_notNested_profiling_20160314_094452.csv, OAK-4119.patch,
> OAK-4119_2.patch, OAK-4119_3.patch, OAK-4119_tests.patch
>
>
> First bunch of potential improvements to be tested/verified using the
> benchmarks:
> h4. General
> - dedicated index for {{rep:members}} property defined by nt
> {{rep:MemberReferences}} (=> mod in {{UserInitializer}})
> - -adjust nt-handling in {{IdentifierManager.getReferences}} : if a single nt
> name is specified in the {{nodeTypeNames}} param it is inserted in the query
> statement instead of looking for {{nt:base}}-
> - simplified, new version of {{IdentifierManager.getReferences}} to match
> needs of membership lookup where propName and a single nt-name is given. see
> below (in OAK-4119_3.patch)
> - introduce {{hasAnyReferenceInPath}}, which allows to search for any
> references being located in a give subtree of the repository (escaping fixed
> in OAK-4119_3.patch)
> - {{MembershipProvider.MemberReferenceIterator}}: keeping track of processed
> references is optional i.e. an implementation detail
> - {{MembershipProvider.AbstractMemberIterator}}: no more protected fields
> (patch OAK-4119_2)
> - {{MembershipProvider.AbstractMemberIterator}}: breadth-first iteration
> before performing queries for the inherited members/membership (patch
> OAK-4119_2)
> h4. Group.isMember
> - {{MembershipProvider}}: introduce shortcut if a Group doesn't have any
> members
> - {{MembershipProvider}}: keep old logic if the target Group has
> (potentially) pending changes
> - {{MembershipProvider}}: for unmodified Groups use reverse membership
> lookup of the target authorizable instead (patch OAK-4119_2: further
> optimizes 'hasMembership' as the {{AbstractMemberIterator}} doesn't need to
> search for the complete membership; limiting the number of queries to be
> executed. see above)
> - {{GroupImpl}}: add shortcut if member to be tested is a Group representing
> the {{EveryonePrincipal}}
> h4. Group.isDeclaredMember
> - introduce shortcut if a Group doesn't have any members
> - keep old logic if target Group (potentially) has pending changes or if the
> number of members is small (=> threshold with {{MembershipProvider}})
> - minor change with the old behavior, which does no longer keep track of
> processed references, which is not needed here
> - for unmodified Groups with plenty of members use
> {{IdentifierManager.hasAnyReferenceInPath}}
> - All modifications in {{MembershipProvider}}
> h4. Group.addMember(Authorizable)
> - {{GroupImpl}}: drop extra test for circular membership, which is anyway
> enforced by the {{UserValidator}} => needs adjustment of test-cases that
> expect this to be detected immediately => intoducing save-call to verify if
> cycles are properly detected latest during commit.
> - {{UserValidator}}: if {{isMember}} is improved by the changes above, the
> check for circular membership would be faster as well
> h4. Group.addMembers(String...)
> - introduce new methods on {{MembershipProvider}} and {{MembershipWriter}}
> that don't take a single contentID but rather a Map of contentID:memberID and
> returns the set of memberIDs that could not be processed successfully.
> - consequently finding the best {{rep:members property}} and avoiding
> duplicate membership is performed only once for the batch of ids to be added
> - Note: once best-property reaches threshold new member-ref nodes
[jira] [Commented] (OAK-4087) Replace Sync of configured AutoMembership by Dynamic Principal Generation
[
https://issues.apache.org/jira/browse/OAK-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178339#comment-15178339
]
Tobias Bocanegra commented on OAK-4087:
---
I think that is a very good idea. I don't know why we didn't thought of that
from the beginning - maybe the dynamic principal provider support wasn't
finalized at that stage. the current config is also very trivial, as it does
not allow fine grained control of the groups.
> Replace Sync of configured AutoMembership by Dynamic Principal Generation
> -
>
> Key: OAK-4087
> URL: https://issues.apache.org/jira/browse/OAK-4087
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
> Labels: performance
>
> the {{DefaultSyncConfig}} comes with a configuration option
> {{PARAM_USER_AUTO_MEMBERSHIP}} indicating the set of groups a given external
> user must always become member of upon sync into the repository.
> this results in groups containing almost all users in the system (at least
> those synchronized form the external IDP). while this behavior is straight
> forward (and corresponds to the behavior in the previous crx version), it
> wouldn't be necessary from a repository point of view as a given {{Subject}}
> can be populated from different principal sources and dealing with this kind
> of dynamic-auto-membership was a typical use-case.
> what does that mean:
> instead of performing the automembership on the user management, the external
> authentication setup could come with an auto-membership {{PrincipalProvider}}
> implementation that would expose the desired group membership for all
> external principals (assuming that they were identified as such).
> [~tripod], do you remember if that was ever an option while building the
> {{oak-auth-external}} module? if not, could that be worth a second thought
> also in the light of OAK-3933?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3933) potential improvements to membership management
[ https://issues.apache.org/jira/browse/OAK-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174855#comment-15174855 ] Tobias Bocanegra commented on OAK-3933: --- wouldn't it make sense to have a generic 'fast-hashset-multivalue-property' that is backed by the persistence layer? since all the values are unique and a UUID, that should be certainly optimized. Having support from the persistence layer would be beneficial than having the application code come up with smart datastructures. > potential improvements to membership management > --- > > Key: OAK-3933 > URL: https://issues.apache.org/jira/browse/OAK-3933 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Julian Reschke >Assignee: angela > > Membership information of a group currently is stored as an unsorted set of > IDs, spread over multiple child nodes, using multivalued properties (of 1000 > each). > This content structure makes certain operations relatively slow: > 1) Checking for declared membership > When the authorizable to be checked is not a member, all child nodes need to > be read and examined (in the other case, checking stops when a match is > found). > 2) Checking for inherited membership > The membership IDs do not reveal the type of authorizable. In order to check > inherited membership as well, the authorizable with the given ID needs to be > read from storage in order to check the type. > Below are a few ideas how this might be improved (however, the change of > structure would require a mgiration step). > 1) Avoid having to read all child nodes to check declared membership > Assuming an alphanumeric ID structure, this could be achieved my modifying > the structure like that: > - as before, start with a single node > - when a new member needs to be inserted and the candidate node is already > full (has 1000 entries), create a new child node named after the first > character of the authorizable ID > - when this "level 1" member is full, start using "level 2" members and so on > (assuming the ID structure is suitable for that, otherwise a different hash > could be used) > To check for membership, we wouldn't need to read *all* child nodes, but only > those where the node name is a prefix match of the ID. > 2) Avoid having to instantiate authorizables for declared membership checks > - put limited type information into the stored IDs, such as "u" and "g" > prefixes; that way the code could identify authorizables that are users and > avoid having to instantiate them > (this assumes that an ID that refers to a user will never refer to a group in > the future) > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3886) Delegate supported Credentials types to ExternalIdentityProvider
[
https://issues.apache.org/jira/browse/OAK-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148951#comment-15148951
]
Tobias Bocanegra edited comment on OAK-3886 at 2/16/16 5:30 PM:
Thanks! (a git pull request would be easier to comment on..)
bq. public interface SupportedCredentials
I don't like the name of this class, as it is used as provider interface for
the IDP. how about {{CredentialsSupport}}. Or even add a 2nd interface
{{CredentialsSupportProvider}} that has a {{CredentialsSupport
getCredentialsSupport()}}. this way, the {{getUserId(Credentials)}} doesn't
look awkward on the IDP impl.
bq. * implemenation and the corresponding {@link ExternalIdentityProvider}.
typo.
bq. supportedCredentials = SupportedCredentialsImpl.getInstance();
getInstance() is a bit confusing. how about {{getDefaultSupport()}} ?
bq. Object logId = (userId != null) ? userId : credentials;
could be {{final}}
bq. ExternalLoginModuleFactory
...has an unrelated change
bq. ExternalLoginModuleFactoryTest
...has an unrelated change
other than that, it looks ok.
was (Author: tripod):
Thanks! (a git pull request would be easier to comment on..)
> public interface SupportedCredentials
I don't like the name of this class, as it is used as provider interface for
the IDP. how about {{CredentialsSupport}}. Or even add a 2nd interface
{{CredentialsSupportProvider}} that has a {{CredentialsSupport
getCredentialsSupport()}}. this way, the {{getUserId(Credentials)}} doesn't
look awkward on the IDP impl.
> * implemenation and the corresponding {@link ExternalIdentityProvider}.
typo.
> supportedCredentials = SupportedCredentialsImpl.getInstance();
getInstance() is a bit confusing. how about {{getDefaultSupport()}} ?
> Object logId = (userId != null) ? userId : credentials;
could be {{final}}
> ExternalLoginModuleFactory
...has an unrelated change
> ExternalLoginModuleFactoryTest
...has an unrelated change
other than that, it looks ok.
> Delegate supported Credentials types to ExternalIdentityProvider
>
>
> Key: OAK-3886
> URL: https://issues.apache.org/jira/browse/OAK-3886
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
> Attachments: OAK-3886.patch
>
>
> Currently, the ExternalLoginModule [only supports
> SimpleCredentials|https://github.com/apache/jackrabbit-oak/blob/cc78f6fdd122d1c9f200b43fc2b9536518ea996b/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L415-L419].
> As the TODO says, it would be good to allow the ExternalIdentityProvider
> specify the supported types, in case they have custom authentication schemes
> that don't fit the username + password pattern of the SimpleCredentials.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3886) Delegate supported Credentials types to ExternalIdentityProvider
[
https://issues.apache.org/jira/browse/OAK-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148951#comment-15148951
]
Tobias Bocanegra commented on OAK-3886:
---
Thanks! (a git pull request would be easier to comment on..)
> public interface SupportedCredentials
I don't like the name of this class, as it is used as provider interface for
the IDP. how about {{CredentialsSupport}}. Or even add a 2nd interface
{{CredentialsSupportProvider}} that has a {{CredentialsSupport
getCredentialsSupport()}}. this way, the {{getUserId(Credentials)}} doesn't
look awkward on the IDP impl.
> * implemenation and the corresponding {@link ExternalIdentityProvider}.
typo.
> supportedCredentials = SupportedCredentialsImpl.getInstance();
getInstance() is a bit confusing. how about {{getDefaultSupport()}} ?
> Object logId = (userId != null) ? userId : credentials;
could be {{final}}
> ExternalLoginModuleFactory
...has an unrelated change
> ExternalLoginModuleFactoryTest
...has an unrelated change
other than that, it looks ok.
> Delegate supported Credentials types to ExternalIdentityProvider
>
>
> Key: OAK-3886
> URL: https://issues.apache.org/jira/browse/OAK-3886
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Alexander Klimetschek
> Attachments: OAK-3886.patch
>
>
> Currently, the ExternalLoginModule [only supports
> SimpleCredentials|https://github.com/apache/jackrabbit-oak/blob/cc78f6fdd122d1c9f200b43fc2b9536518ea996b/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/ExternalLoginModule.java#L415-L419].
> As the TODO says, it would be good to allow the ExternalIdentityProvider
> specify the supported types, in case they have custom authentication schemes
> that don't fit the username + password pattern of the SimpleCredentials.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3930) Sysview import of single valued mv property creates sv property
[ https://issues.apache.org/jira/browse/OAK-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated OAK-3930: -- Description: See test in filevault [0]. it imports a multivalue property that only has 1 value, via [1]. the same test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 [0] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 [1] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 was: See test in filevault [0]. it imports a multivalue property that only has 1 value, via [1]. the same test succeeds in jackrabbit 2.0, but fails in oak 1.3.9 [0] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 [1] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 > Sysview import of single valued mv property creates sv property > --- > > Key: OAK-3930 > URL: https://issues.apache.org/jira/browse/OAK-3930 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr >Affects Versions: 1.3.14 >Reporter: Tobias Bocanegra > > See test in filevault [0]. > it imports a multivalue property that only has 1 value, via [1]. the same > test succeeds in jackrabbit 2.0, but fails in oak 1.3.14 > [0] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 > [1] > https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3930) Sysview import of single valued mv property creates sv property
Tobias Bocanegra created OAK-3930: - Summary: Sysview import of single valued mv property creates sv property Key: OAK-3930 URL: https://issues.apache.org/jira/browse/OAK-3930 Project: Jackrabbit Oak Issue Type: Bug Components: jcr Affects Versions: 1.3.14 Reporter: Tobias Bocanegra See test in filevault [0]. it imports a multivalue property that only has 1 value, via [1]. the same test succeeds in jackrabbit 2.0, but fails in oak 1.3.9 [0] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/TestUserContentPackage.java#L297-L326 [1] https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.1.26/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JcrSysViewTransformer.java#L146-L148 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3842) Adjust package export declarations
[ https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092248#comment-15092248 ] Tobias Bocanegra commented on OAK-3842: --- yes, remove the export. thanks. > Adjust package export declarations > --- > > Key: OAK-3842 > URL: https://issues.apache.org/jira/browse/OAK-3842 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Critical > Labels: api, modularization, technical_debt > Fix For: 1.4 > > > We need to adjust the package export declarations such that they become > manageable with our branch / release model. > See http://markmail.org/thread/5g3viq5pwtdryapr for discussion. > I propose to remove package export declarations from all packages that we > don't consider public API / SPI beyond Oak itself. This would allow us to > evolve Oak internal stuff (e.g. things used across Oak modules) freely > without having to worry about merges to branches messing up semantic > versioning. OTOH it would force us to keep externally facing public API / SPI > reasonably stable also across the branches. Furthermore such an approach > would send the right signal to Oak API / SPI consumers regarding the > stability assumptions they can make. > An external API / SPI having a (transitive) dependency on internals might be > troublesome. In doubt I would remove the export version here until we can > make reasonable guarantees (either through decoupling the code or stabilising > the dependencies). > I would start digging through the export version and prepare an initial > proposal for further discussion. > /cc [~frm], [~chetanm], [~mmarth] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3519) Some improvement to SyncMBeanImpl
[
https://issues.apache.org/jira/browse/OAK-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061004#comment-15061004
]
Tobias Bocanegra commented on OAK-3519:
---
+1 LGTM
but I would make the {{SyncRuntimeException}} public. there is no reason to
have it package protected. especially since the methods are indirectly called
via puplic ones.
> Some improvement to SyncMBeanImpl
> -
>
> Key: OAK-3519
> URL: https://issues.apache.org/jira/browse/OAK-3519
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Attachments: OAK-3519.patch, OAK-3519_2.patch, OAK-3519_3.patch
>
>
> IMHO the {{SyncMBeanImpl}} deserves some improvement:
> - code duplication
> - overall readability
> - removing catching {{Exception}}
> - throwing {{IllegalArgument}} when no argument has been provided instead of
> a dedicated {{RuntimeException}} indicating that the operation could not be
> successfully completed
> - more consistency in variable naming (e.g. the list of strings computed in
> the various operations is sometimes called {{list}} and sometimes {{result}})
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3275) DefaultSyncConfig: User membership expiration time not working under some circumstances
[
https://issues.apache.org/jira/browse/OAK-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060588#comment-15060588
]
Tobias Bocanegra commented on OAK-3275:
---
+1 LGTM
> DefaultSyncConfig: User membership expiration time not working under some
> circumstances
> ---
>
> Key: OAK-3275
> URL: https://issues.apache.org/jira/browse/OAK-3275
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.5
>Reporter: Konrad Windszus
>
> Currently the user expiration and the user membership expiration can be set
> independently of each other in the OSGi configuration for the
> {{DefaultSyncConfigImpl}}.
> In reality this is not true though:
> Not only can the membership not be updated more often than the other user
> properties (compare with OAK-3274).
> Also the property which is used to mark the last successfull sync is the same
> for both synchronisations
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L433
> and
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L422).
> That is a problem if e.g. the user expiration time is 10 minutes but the user
> membership expiration time is 1 hour. Then every 10 minutes the property
> {{rep:lastSynced}} would be updated to the current time and the expiration
> check for the membership expiration would never return true
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L433).
> Therefore memberships would never be updated!
> I suggest to completely get rid of user membership expiration time and only
> have one expiration time for both the user properties and the memberships.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3275) DefaultSyncConfig: User membership expiration time not working under some circumstances
[
https://issues.apache.org/jira/browse/OAK-3275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058436#comment-15058436
]
Tobias Bocanegra commented on OAK-3275:
---
I don't know if we really should remove this and not better fix the issue. if
the nesting depth is larger and the amount of groups to sync is substantial, it
makes sense to have a longer or (even disabled) membership sync. so we'd rather
add another property to the authorizable, eg: {{rep:lastSyncedMembers}}.
a minor issue to this patch is, that it does remove and not deprecate the
config methods, making it not backward compatible.
> DefaultSyncConfig: User membership expiration time not working under some
> circumstances
> ---
>
> Key: OAK-3275
> URL: https://issues.apache.org/jira/browse/OAK-3275
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.5
>Reporter: Konrad Windszus
>
> Currently the user expiration and the user membership expiration can be set
> independently of each other in the OSGi configuration for the
> {{DefaultSyncConfigImpl}}.
> In reality this is not true though:
> Not only can the membership not be updated more often than the other user
> properties (compare with OAK-3274).
> Also the property which is used to mark the last successfull sync is the same
> for both synchronisations
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L433
> and
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L422).
> That is a problem if e.g. the user expiration time is 10 minutes but the user
> membership expiration time is 1 hour. Then every 10 minutes the property
> {{rep:lastSynced}} would be updated to the current time and the expiration
> check for the membership expiration would never return true
> (https://github.com/apache/jackrabbit-oak/blob/trunk/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/basic/DefaultSyncContext.java#L433).
> Therefore memberships would never be updated!
> I suggest to completely get rid of user membership expiration time and only
> have one expiration time for both the user properties and the memberships.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3721) Reduce code duplication in MembershipProvider
[
https://issues.apache.org/jira/browse/OAK-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047249#comment-15047249
]
Tobias Bocanegra commented on OAK-3721:
---
in general ok. but I don't like the access of the protected variables
{{references}} and {{parent}} from the anonymous classes, because they also
influence the iteration logic in the abstract class. i.e. It is hard to
understand how the code flows.
> Reduce code duplication in MembershipProvider
> -
>
> Key: OAK-3721
> URL: https://issues.apache.org/jira/browse/OAK-3721
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.3.13
>
> Attachments: OAK-3721.patch
>
>
> minor improvement to the {{MembershipProvider}} to get rid of the code
> duplication in the member-iterator that is present twice.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3508:
--
Fix Version/s: 1.0.23
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4, 1.0.23
>
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014123#comment-15014123
]
Tobias Bocanegra commented on OAK-2948:
---
yeah, the {{DefaultSyncConfigImpl}} separates the configuration for the
{{DefaultSyncHandler}}:
{noformat}
@Component(
label = "Apache Jackrabbit Oak Default Sync Handler",
name =
"org.apache.jackrabbit.oak.spi.security.authentication.external.impl.DefaultSyncHandler",
configurationFactory = true,
metatype = true,
ds = false
)
{noformat}
so basically it's the same as if it would be in the same class as
DefaultSyncHandler. we just separated it so that we can have a own pojo for the
config for non osgi use cases.
If you create your own sync handler, you obviously need your own component
configuration. currently, you need to copy-paste it. correct.
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011568#comment-15011568
]
Tobias Bocanegra commented on OAK-2948:
---
no, the class is public:
{{org.apache.jackrabbit.oak.spi.security.authentication.external.basic.DefaultSyncConfig}}
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3522) DefaultSyncContext exposes internal path-utility method
[
https://issues.apache.org/jira/browse/OAK-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002713#comment-15002713
]
Tobias Bocanegra commented on OAK-3522:
---
+1
thanks!
> DefaultSyncContext exposes internal path-utility method
> ---
>
> Key: OAK-3522
> URL: https://issues.apache.org/jira/browse/OAK-3522
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Attachments: OAK-3522.patch, OAK-3522_2.patch, OAK-3522_3.patch
>
>
> the {{DefaultSyncContext}} defines a public static method {{joinPaths}},
> which IMHO should not be exposed as it is unrelated to the functionality
> defined by the {{DefaultSyncContext}}.
> i would therefore suggest to make it private (and increase the package
> version to 2.0.0)... we can then still decide to move this utility to
> {{PathUtils}} in oak-commons.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3626) Provide bind credentials callback
Tobias Bocanegra created OAK-3626: - Summary: Provide bind credentials callback Key: OAK-3626 URL: https://issues.apache.org/jira/browse/OAK-3626 Project: Jackrabbit Oak Issue Type: Improvement Components: auth-ldap Reporter: Tobias Bocanegra The ldap identity provider reads the admin bind credentials from the given config which might originate from a un-encrypted source (eg. osgi config). in order to facilitate secure provisioning of the bind credentials, the ldap idp should offer some sort of credentials provider callback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3523) DefaultSyncContext catches ClassCastException
[
https://issues.apache.org/jira/browse/OAK-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14963649#comment-14963649
]
Tobias Bocanegra commented on OAK-3523:
---
also I think that {{Group grp = userManager.getAuthorizable(extGroup.getId(),
Group.class);}} is not backwards compatible...we should keep this code as
portable as possible, as we need to backport fixes often.
> DefaultSyncContext catches ClassCastException
> -
>
> Key: OAK-3523
> URL: https://issues.apache.org/jira/browse/OAK-3523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
> Labels: technical_debt
> Attachments: OAK-3523.patch, OAK-3523_3.patch, OAK-3523_test.patch
>
>
> the group and group-member sync code in the {{DefaultSyncContext}} twice
> catches {{ClassCastException}} and swallows exception situations, where a
> user is found, when actually a {{Group}} was expected.
> i would suggest to
> - explicitly test the assumption wrt {{ExternalIdentity}} being a group
> (instead of waiting for the exception)
> - make use of {{UserManager.getAuthorizable(String, Class) to explicitly
> retrieve a Group with a given ID, when this is actually expected. This method
> will throws an {{AuthorizableTypeException}} if there exists a {{User}} with
> that ID as thus properly raise the unexpected behavior instead of swallowing
> with a log-warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3523) DefaultSyncContext catches ClassCastException
[
https://issues.apache.org/jira/browse/OAK-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961320#comment-14961320
]
Tobias Bocanegra commented on OAK-3523:
---
I disagree with the patch. it is less performant...i'll have a closer look
again
> DefaultSyncContext catches ClassCastException
> -
>
> Key: OAK-3523
> URL: https://issues.apache.org/jira/browse/OAK-3523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: angela
> Labels: technical_debt
> Attachments: OAK-3523.patch, OAK-3523_3.patch, OAK-3523_test.patch
>
>
> the group and group-member sync code in the {{DefaultSyncContext}} twice
> catches {{ClassCastException}} and swallows exception situations, where a
> user is found, when actually a {{Group}} was expected.
> i would suggest to
> - explicitly test the assumption wrt {{ExternalIdentity}} being a group
> (instead of waiting for the exception)
> - make use of {{UserManager.getAuthorizable(String, Class) to explicitly
> retrieve a Group with a given ID, when this is actually expected. This method
> will throws an {{AuthorizableTypeException}} if there exists a {{User}} with
> that ID as thus properly raise the unexpected behavior instead of swallowing
> with a log-warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3523) DefaultSyncContext catches ClassCastException
[
https://issues.apache.org/jira/browse/OAK-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned OAK-3523:
-
Assignee: Tobias Bocanegra (was: angela)
> DefaultSyncContext catches ClassCastException
> -
>
> Key: OAK-3523
> URL: https://issues.apache.org/jira/browse/OAK-3523
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Reporter: angela
>Assignee: Tobias Bocanegra
> Labels: technical_debt
> Attachments: OAK-3523.patch, OAK-3523_3.patch, OAK-3523_test.patch
>
>
> the group and group-member sync code in the {{DefaultSyncContext}} twice
> catches {{ClassCastException}} and swallows exception situations, where a
> user is found, when actually a {{Group}} was expected.
> i would suggest to
> - explicitly test the assumption wrt {{ExternalIdentity}} being a group
> (instead of waiting for the exception)
> - make use of {{UserManager.getAuthorizable(String, Class) to explicitly
> retrieve a Group with a given ID, when this is actually expected. This method
> will throws an {{AuthorizableTypeException}} if there exists a {{User}} with
> that ID as thus properly raise the unexpected behavior instead of swallowing
> with a log-warning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3518) Consistently add annotations to DefaultSync* classes
[
https://issues.apache.org/jira/browse/OAK-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957450#comment-14957450
]
Tobias Bocanegra commented on OAK-3518:
---
looks good
> Consistently add annotations to DefaultSync* classes
>
>
> Key: OAK-3518
> URL: https://issues.apache.org/jira/browse/OAK-3518
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: angela
>Assignee: angela
>Priority: Trivial
> Attachments: OAK-3518.patch
>
>
> the public classes in
> {{org.apache.jackrabbit.oak.spi.security.authentication.external.basic}}
> package should have consistent annotations such {{@Nonnull}},
> {{@CheckForNull}} (etc) as well as {{@Override}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956062#comment-14956062
]
Tobias Bocanegra commented on OAK-3508:
---
fixed in 1.0: r1708541
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4
>
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3508.
---
Resolution: Fixed
Fix Version/s: 1.4
fixed in trunk: r1708540
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 1.4
>
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3498) DN can't be used as the group name in the external auth handler
[
https://issues.apache.org/jira/browse/OAK-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955155#comment-14955155
]
Tobias Bocanegra commented on OAK-3498:
---
Those are 2 issues. one is using the DN as name/id attribute, the other is
finding the authorizable via principal name. I think the first is valid, the
2nd not.
please create separate issues and patches. the changes in the
LdapIdentityProvider look ok.
> DN can't be used as the group name in the external auth handler
> ---
>
> Key: OAK-3498
> URL: https://issues.apache.org/jira/browse/OAK-3498
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.3.7, 1.2.7, 1.0.22
>Reporter: Tomek Rękawek
> Attachments: OAK-3498-1.0.patch, OAK-3498-trunk.patch
>
>
> One of the users wants to migrate his repository from Jackrabbit 2 to Oak. He
> uses LDAP for authentication. The LDAP synchronization in Jackrabbit 2 is
> configured in such manner, that both principal id and authorizable name is
> set to the DN (eg. {{CN=my-group,OU=abc,...}}).
> After migration to Oak LDAP users can't login. The reason is that during the
> login, the {{DefaultSyncContext}} tries to synchronize all groups memberships
> and create missing groups. By default it uses CN as the group name and tries
> to find it. It fails, because the migrated group has a name created with its
> DN. It assumes that the group doesn't exist and then wants to create it -
> which fails as well, because group with the given principal name already
> exists. As a result, the whole login process fails.
> The LDAP attribute to be used as the group name can be configured. However,
> the DN is not an attribute, so setting {{group.nameAttribute="dn"}} in
> {{LdapProviderConfig}} results in a {{NullPointerException}}.
> I think two things can be improved here:
> 1. {{DefaultSyncContext}} should try to find a group using its principal name
> rather than group id.
> 2. It should be possible to use DN as the {{group.nameAttribute}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955083#comment-14955083
]
Tobias Bocanegra edited comment on OAK-3508 at 10/13/15 3:14 PM:
-
So basically this issue is about reducing LDAP lookups for local users and
reducing LDAP syncs for users that are already authenticated.
was (Author: tripod):
So basically this issue is about to reduce LDAP lookups for local users and
reduce LDAP syncs for users that are already authenticated.
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955083#comment-14955083
]
Tobias Bocanegra commented on OAK-3508:
---
So basically this issue is about to reduce LDAP lookups for local users and
reduce LDAP syncs for users that are already authenticated.
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955049#comment-14955049
]
Tobias Bocanegra commented on OAK-3508:
---
no quite. our SSO module only sets the shared credentials, it does not return
*TRUE* on login:
{code}
public boolean login() throws LoginException {
Credentials credentials = getCredentials();
if (credentials instanceof SSOCredentials) {
userId = ((SSOCredentials) credentials).getUserId();
if (userId == null) {
log.debug("Could not extract userId/credentials");
} else {
// we just set the login name and rely on the following login
modules to populate the subject
sharedState.put(SHARED_KEY_PRE_AUTH_LOGIN, new
PreAuthenticatedLogin(userId));
sharedState.put(SHARED_KEY_CREDENTIALS, new
SimpleCredentials(userId, new char[0]));
sharedState.put(SHARED_KEY_LOGIN_NAME, userId);
log.debug("login succeeded with trusted user: {}", userId);
}
}
return false;
}
{code}
This was done this ways to keep the entire user lookup and subject populating
in the default login module, i.e. make the SSO login module user manager
agnostic.
The only other option is to swap the default and external login module and keep
them sufficient. this way the external login module always is treated first.
the only fear is with uid collisions for users that exist in LDAP and the local
repository (e.g. admin). but since they are lacking the {{ref:externalId}}
flag, the external login module should ignore them.
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3508:
--
Affects Version/s: 1.4
1.2
1.0.22
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned OAK-3508:
-
Assignee: Tobias Bocanegra
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
Tobias Bocanegra created OAK-3508:
-
Summary: External login module should reduce LDAP lookups for
pre-authenticated users
Key: OAK-3508
URL: https://issues.apache.org/jira/browse/OAK-3508
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Tobias Bocanegra
consider the following JAAS setup:
- *sufficient* SSO Login Module
- *optional* Default Login Module
- *sufficient* External Login Module
This causes each login() to reach the external login module (which is desired)
but causes an IDP lookup for each login, even if the user is already synced
with the repository.
ideally the login module could pass the {{ExternalIdentityRef}} to the sync
handler and to a tentative sync. the {{lastSyncTime}} should be respected in
this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3508) External login module should reduce LDAP lookups for pre-authenticated users
[
https://issues.apache.org/jira/browse/OAK-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3508:
--
Component/s: auth-external
> External login module should reduce LDAP lookups for pre-authenticated users
>
>
> Key: OAK-3508
> URL: https://issues.apache.org/jira/browse/OAK-3508
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Affects Versions: 1.2, 1.4, 1.0.22
>Reporter: Tobias Bocanegra
>
> consider the following JAAS setup:
> - *sufficient* SSO Login Module
> - *optional* Default Login Module
> - *sufficient* External Login Module
> This causes each login() to reach the external login module (which is
> desired) but causes an IDP lookup for each login, even if the user is already
> synced with the repository.
> ideally the login module could pass the {{ExternalIdentityRef}} to the sync
> handler and to a tentative sync. the {{lastSyncTime}} should be respected in
> this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3396.
---
Resolution: Fixed
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941611#comment-14941611
]
Tobias Bocanegra commented on OAK-3311:
---
fixed in 1.0: r1706478
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941610#comment-14941610
]
Tobias Bocanegra commented on OAK-3396:
---
fixed in 1.0: r1706476
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3311.
---
Resolution: Fixed
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941556#comment-14941556
]
Tobias Bocanegra commented on OAK-3311:
---
fixed in 1.2: r1706465
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941555#comment-14941555
]
Tobias Bocanegra commented on OAK-3396:
---
fixed in 1.2: r1706463
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941513#comment-14941513
]
Tobias Bocanegra commented on OAK-3396:
---
fixed in trunk: r1706457
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941508#comment-14941508
]
Tobias Bocanegra commented on OAK-3311:
---
fixed in trunk: r1706459
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941476#comment-14941476
]
Tobias Bocanegra commented on OAK-3311:
---
bq. missing test-case verifying that the issue is actually valid and that the
patch actually addresses it.
unfortunately, I don't know how to create a test case here, since the MBean
needs a JCR repository, but the test is in oak. either there is an easy way to
retrieve the repository, or we need to rewrite the sync handler to use oak
directly instead of JCR - or at least the MBean.
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3311) Potential NPE in syncAllExternalUsers() aborts the process
[
https://issues.apache.org/jira/browse/OAK-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3311:
--
Fix Version/s: 1.2.7
1.3.9
> Potential NPE in syncAllExternalUsers() aborts the process
> --
>
> Key: OAK-3311
> URL: https://issues.apache.org/jira/browse/OAK-3311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external
>Affects Versions: 1.2.4, 1.3.4, 1.0.19
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.9, 1.2.7, 1.0.22
>
> Attachments: OAK-3311-1.0.19.patch
>
>
> The iteration over all users in {{syncAllExternalUsers()}} aborts if there is
> an uncaught NPE.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-3396:
--
Fix Version/s: 1.2.7
1.3.8
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Blocker
> Fix For: 1.3.8, 1.2.7, 1.0.22
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-2948:
--
Fix Version/s: 1.0.22
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra updated OAK-2948:
--
Fix Version/s: 1.2.7
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768956#comment-14768956
]
Tobias Bocanegra commented on OAK-3396:
---
[~egli] we could import the users and groups normally, but use a different
config for the identifier attribute.
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch, OAK-3396.patch.v2
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned OAK-3396:
-
Assignee: Tobias Bocanegra
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Assignee: Tobias Bocanegra
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3396) NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
[
https://issues.apache.org/jira/browse/OAK-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745601#comment-14745601
]
Tobias Bocanegra commented on OAK-3396:
---
[~egli] thanks. can you also create a test case?
> NPE during syncAllExternalUsers in LdapIdentityProvider.createUser
> --
>
> Key: OAK-3396
> URL: https://issues.apache.org/jira/browse/OAK-3396
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-ldap
>Affects Versions: 1.0.18
>Reporter: Stefan Egli
>Priority: Minor
> Fix For: 1.0.20
>
> Attachments: OAK-3396.patch
>
>
> When executing the JMX method syncAllExternalUsers the following NPE has been
> encountered. This likely indicates that - for a particular user - there is no
> attribute '{{uid}}':
> {code}
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.createUser(LdapIdentityProvider.java:667)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider.access$000(LdapIdentityProvider.java:88)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:281)
> at
> org.apache.jackrabbit.oak.security.authentication.ldap.impl.LdapIdentityProvider$1.getNext(LdapIdentityProvider.java:273)
> at
> org.apache.jackrabbit.commons.iterator.AbstractLazyIterator.hasNext(AbstractLazyIterator.java:39)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl$Delegatee.syncAllExternalUsers(SyncMBeanImpl.java:245)
> at
> org.apache.jackrabbit.oak.spi.security.authentication.external.impl.jmx.SyncMBeanImpl.syncAllExternalUsers(SyncMBeanImpl.java:426)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3351) Add ability to prioritise restriction to where it matches
[
https://issues.apache.org/jira/browse/OAK-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved OAK-3351.
---
Resolution: Won't Fix
> Add ability to prioritise restriction to where it matches
> -
>
> Key: OAK-3351
> URL: https://issues.apache.org/jira/browse/OAK-3351
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>Priority: Minor
>
> Consider the following use case:
> A node, and not its subtree, should be protected from removal, if it contains
> a defined property. a custom jcr:protected so to speak.
> The idea is to create a restriction provider that enables the ACE when the
> property is set. for example:
> {noformat}
> allow rep:read,rep:write /a
> deny jcr:removeNode /a hasProperty=protect-me
> allow jcr:removeNode /a hasProperty=!protect-me
> {noformat}
> the _allow_ is needed so that the child nodes of a protected node are still
> removable, if they are not protected themselves.
> The problem is now, that the ACE does not apply where it matches, but where
> it is defined.
> so assume we have a node {{/a/b/c}} protected. the ACE in {{/a}} would then
> match the node, but also the parent {{/a/b}} if it is not protected would
> match the allow rule, since the REMOVE_NODE is a permission that also needs
> to check the REMOVE_CHILDNODES privilege on the parent. And since the allow
> ACE is after the deny one, it wins.
> So either the parent-check needs to be delayed to a later stage, or we can
> define that an ACE with restriction can be sorted in a way that it applies
> where it matches, so that it looks like the ACE was specified on {{/a/b/c}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
