[jira] [Assigned] (OAK-7793) RDB*Store: provide support for testing with mysql inside docker
[
https://issues.apache.org/jira/browse/OAK-7793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke reassigned OAK-7793:
---
Assignee: Manfred Baedke (was: Julian Reschke)
> RDB*Store: provide support for testing with mysql inside docker
> ---
>
> Key: OAK-7793
> URL: https://issues.apache.org/jira/browse/OAK-7793
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Major
> Attachments: OAK-7793.diff, OAK-7793.diff
>
>
> (wip - testing with)
> {{docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=geheim -e
> MYSQL_DATABASE=oak -p 33060:3306 -d mysql:8 --character-set-server=utf8mb4
> --collation-server=utf8mb4_unicode_ci}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8683) The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is used.
Manfred Baedke created OAK-8683: --- Summary: The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is used. Key: OAK-8683 URL: https://issues.apache.org/jira/browse/OAK-8683 Project: Jackrabbit Oak Issue Type: Bug Components: core-spi Reporter: Manfred Baedke In the absense of an OSGi framework, a newly created Oak instance wouldn't use the OsgiWhiteBoard, but instead fall back to it's own internal implementation extending DefaultWhiteBoard. The WhiteboardUtils.ScheduleExecutionInstanceTypes is then completely ignored when registering the AsynIndexUpdate job (which makes sense since Oak doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing threads running on all cluster nodes and fighting for the index update lease. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8683) The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is used.
[ https://issues.apache.org/jira/browse/OAK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8683: Description: In the absense of an OSGi framework, a newly created Oak instance wouldn't use the OsgiWhiteBoard, but instead fall back to it's own internal implementation extending DefaultWhiteBoard. The WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored when registering the AsyncIndexUpdate job (which makes sense, since Oak doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing threads running on all cluster nodes and fighting for the index update lease. (was: In the absense of an OSGi framework, a newly created Oak instance wouldn't use the OsgiWhiteBoard, but instead fall back to it's own internal implementation extending DefaultWhiteBoard. The WhiteboardUtils.ScheduleExecutionInstanceTypes is then completely ignored when registering the AsynIndexUpdate job (which makes sense since Oak doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing threads running on all cluster nodes and fighting for the index update lease.) > The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard > is used. > - > > Key: OAK-8683 > URL: https://issues.apache.org/jira/browse/OAK-8683 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core-spi >Reporter: Manfred Baedke >Priority: Minor > > In the absense of an OSGi framework, a newly created Oak instance wouldn't > use the OsgiWhiteBoard, but instead fall back to it's own internal > implementation extending DefaultWhiteBoard. The > WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored > when registering the AsyncIndexUpdate job (which makes sense, since Oak > doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing > threads running on all cluster nodes and fighting for the index update lease. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8683) The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is used.
[ https://issues.apache.org/jira/browse/OAK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned OAK-8683: --- Assignee: Manfred Baedke > The async indexing thread runs on all cluster nodes if the DefaultWhiteBoard > is used. > - > > Key: OAK-8683 > URL: https://issues.apache.org/jira/browse/OAK-8683 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core-spi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > In the absense of an OSGi framework, a newly created Oak instance wouldn't > use the OsgiWhiteBoard, but instead fall back to it's own internal > implementation extending DefaultWhiteBoard. The > WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored > when registering the AsyncIndexUpdate job (which makes sense, since Oak > doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing > threads running on all cluster nodes and fighting for the index update lease. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8683) Async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is used
[ https://issues.apache.org/jira/browse/OAK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8683: Description: In the absense of an OSGi framework, a newly created Oak instance wouldn't use the OsgiWhiteboard, but instead fall back to it's own internal implementation extending DefaultWhiteboard. The WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored when registering the AsyncIndexUpdate job (which makes sense, since Oak doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing threads running on all cluster nodes and fighting for the index update lease. This will occasionally produce exceptions due to concurrent updates. (was: In the absense of an OSGi framework, a newly created Oak instance wouldn't use the OsgiWhiteBoard, but instead fall back to it's own internal implementation extending DefaultWhiteBoard. The WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored when registering the AsyncIndexUpdate job (which makes sense, since Oak doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing threads running on all cluster nodes and fighting for the index update lease.) > Async indexing thread runs on all cluster nodes if the DefaultWhiteBoard is > used > > > Key: OAK-8683 > URL: https://issues.apache.org/jira/browse/OAK-8683 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core-spi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > > In the absense of an OSGi framework, a newly created Oak instance wouldn't > use the OsgiWhiteboard, but instead fall back to it's own internal > implementation extending DefaultWhiteboard. The > WhiteboardUtils.ScheduleExecutionInstanceTypes are then completely ignored > when registering the AsyncIndexUpdate job (which makes sense, since Oak > doesn't understand it's own RUN_ON_LEADER hint), resulting in async indexing > threads running on all cluster nodes and fighting for the index update lease. > This will occasionally produce exceptions due to concurrent updates. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of principals unknown to Oak.
Manfred Baedke created OAK-8710:
---
Summary: AbstractLoginModule#logout() may fail in the presence of
principals unknown to Oak.
Key: OAK-8710
URL: https://issues.apache.org/jira/browse/OAK-8710
Project: Jackrabbit Oak
Issue Type: Bug
Components: security-spi
Reporter: Manfred Baedke
See
https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
The criterion for logout() to succeed is
{code}!subject.getPrincipals().isEmpty() &&
!subject.getPublicCredentials(Credentials.class).isEmpty(){code}
This did not work in a case where the subject was created by a thread handling
an authenticated JMX connection (and later passed on to other threads due to
AccessControlContext inheritage).
I'd propose to make logout() succeed unconditionally, but I'm not entirely sure
about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of principals unknown to Oak.
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-8710:
Description:
See
https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
The criterion for logout() to succeed is
{code}!subject.getPrincipals().isEmpty() &&
!subject.getPublicCredentials(Credentials.class).isEmpty(){code}
This did not work in a case where the subject was created by a thread handling
an authenticated JMX connection (and later passed on to other threads due to
AccessControlContext inheritage).
I'd propose to make logout() succeed unconditionally, but I'm not entirely sure
about side effects.
was:
See
https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
The criterion for logout() to succeed is
{code}!subject.getPrincipals().isEmpty() &&
!subject.getPublicCredentials(Credentials.class).isEmpty(){code}
This did not work in a case where the subject was created by a thread handling
an authenticated JMX connection (and later passed on to other threads due to
AccessControlContext inheritage).
I'd propose to make logout() succeed unconditionally, but I'm not entirely sure
about side effects.
> AbstractLoginModule#logout() may fail in the presence of principals unknown
> to Oak.
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958906#comment-16958906
]
Manfred Baedke commented on OAK-8710:
-
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958906#comment-16958906
]
Manfred Baedke edited comment on OAK-8710 at 10/24/19 3:20 PM:
---
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
Edit: trivial test method to be added to AbstractLoginModuleTest:
{code}
@Test
public void testLogoutAlienPrincipal() {
Subject subject = new Subject(false, ImmutableSet.of(new
PrincipalImpl("foo")), ImmutableSet.of(), ImmutableSet.of());
AbstractLoginModule loginModule = initLoginModule(subject, null, null);
assertTrue(loginModule.logout());
}
{code}
will fail, which clearly breaks the contract.
was (Author: baedke):
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16958906#comment-16958906
]
Manfred Baedke edited comment on OAK-8710 at 10/24/19 3:22 PM:
---
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
Edit: trivial test method to be added to AbstractLoginModuleTest:
{code}
@Test
public void testLogoutAlienPrincipal() {
Subject subject = new Subject(false, ImmutableSet.of(new
PrincipalImpl("foo")), ImmutableSet.of(), ImmutableSet.of());
AbstractLoginModule loginModule = initLoginModule(subject, null, null);
assertTrue(loginModule.logout());
}
{code}
will fail, which clearly breaks the contract (and this type of subject is what
an authenticated JMX connection will give you).
was (Author: baedke):
Hi [~angela],
I'll try to come up with a test case. Not sure yet how that will go.
Please note
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout,
which states a different logout contract.
But you're right, the JavaDoc should matter, so succeeding unconditionally is
not an option. Anyway, we don't implement that contract, too. Currently, the
criterion for success is the presence of any principal and the presence of
public credentials, which has nothing to do with the question if the Module
should be ignored (actually, in the case mentioned in the description, it
certainly should not, because it did the login).
Will we need to keep track of principals?
Edit: trivial test method to be added to AbstractLoginModuleTest:
{code}
@Test
public void testLogoutAlienPrincipal() {
Subject subject = new Subject(false, ImmutableSet.of(new
PrincipalImpl("foo")), ImmutableSet.of(), ImmutableSet.of());
AbstractLoginModule loginModule = initLoginModule(subject, null, null);
assertTrue(loginModule.logout());
}
{code}
will fail, which clearly breaks the contract.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963021#comment-16963021
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
There is no login of an unknown principal. I don't think that the JAAS config
matters here much. The unknown principal comes from the fact that a newly
created thread gets an AccessControlContext which inherits the
AccessControlContext of the creating thread. This may, e.g., be a thread
handling an authenticated JMX connection, in which case it contains a subject
with a principal like "JMXPrincipal: xyz".
So this principal will make it's way into the AccessControlContext of a thread
handling a logout call. If you know a way to avoid that, please let me know.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963967#comment-16963967
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. the test case you provided seems odd to me as it doesn't include the login
step
Yes, because it doesn't test that. Like e.g. testLogoutSuccessClearsSubject(),
it's just about one single aspect of the logout behavior, namely that logout
ignores unknown principals.
Quote from
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASLMDevGuide.html#logout:
"This method removes Principals, and removes/destroys credentials associated
with the Subject during the commit operation. This method should not touch
those Principals or credentials previously existing in the Subject".
I'll send you a link to the describing the scenario where the issue happened.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964365#comment-16964365
]
Manfred Baedke commented on OAK-8710:
-
I'd propose to ignore all principals that are not JackrabbitPrincipals and all
credentials that are not javax.jcr.Credentials.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967521#comment-16967521
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. has methods for getCredentials and getPrincipals, we already have the basic
functionality in place to actually know the credentials/principals that have
been used for the login/commit
That makes sense.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967528#comment-16967528
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. Also, I still think the test case you provided above is not properly
reflecting the scenario you are describing.
Why?
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968404#comment-16968404
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
Re tests: I was trying to keep in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968404#comment-16968404
]
Manfred Baedke edited comment on OAK-8710 at 11/6/19 9:20 PM:
--
[~angela],
Re tests: I was trying to stay in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
was (Author: baedke):
[~angela],
Re tests: I was trying to keep in line with other tests in the same test class
(like testLogoutSuccessClearsSubject()), which test single aspects of the
contract only and also do not login. TestLoginModule#login() doesn't do
anything anyway. But yes, in view of that JAAS tech notes, that needs to be
reworked.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969283#comment-16969283
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. ok. i guess what is really important for the issue at hand is that only
principals/credentials that have been set by the commit of this login module
get removed upon logout (or destroyed in case the subject is readonly
Not quite. I'll attach a debugger screenshot where you can see that the
inherited subject is readonly and there is only one principal. Maybe
LoginContextProviderImpl#getSubject() is the real problem, because in this case
it does not return a pre-authenticated subject created by Oak, but instead the
subject from the inherited AccessControlContext.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-8710:
Attachment: logout.png
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969307#comment-16969307
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
Yes, of course that's a new issue.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969307#comment-16969307
]
Manfred Baedke edited comment on OAK-8710 at 11/7/19 2:39 PM:
--
[~angela],
Yes, of course that's a new issue (which might make this one obsolet). I'm
sorry about the confusion, but here the root cause was just a little hard to
track down.
I'll make a few tests and will open a new issue, if successful.
was (Author: baedke):
[~angela],
Yes, of course that's a new issue.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8710) AbstractLoginModule#logout() may fail in the presence of unknown principals
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16969307#comment-16969307
]
Manfred Baedke edited comment on OAK-8710 at 11/7/19 2:41 PM:
--
[~angela],
Yes, of course that's a new issue. I'm sorry about the confusion, but here the
root cause was just a little hard to track down.
I'll make a few tests and will open a new issue, if successful.
was (Author: baedke):
[~angela],
Yes, of course that's a new issue (which might make this one obsolet). I'm
sorry about the confusion, but here the root cause was just a little hard to
track down.
I'll make a few tests and will open a new issue, if successful.
> AbstractLoginModule#logout() may fail in the presence of unknown principals
> ---
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
Manfred Baedke created OAK-8763: --- Summary: LoginContextProviderImpl uses any subject found in the AccessControlContext. Key: OAK-8763 URL: https://issues.apache.org/jira/browse/OAK-8763 Project: Jackrabbit Oak Issue Type: Bug Components: security-spi Reporter: Manfred Baedke Assignee: Angela Schreiber LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume. that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Description: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. (was: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume. that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials.) > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Description: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. was:LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973480#comment-16973480 ] Manfred Baedke edited comment on OAK-8763 at 11/13/19 4:10 PM: --- See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject). was (Author: baedke): See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973480#comment-16973480 ] Manfred Baedke commented on OAK-8763: - See https://issues.apache.org/jira/secure/attachment/12985222/logout.png for an example of a preexisting readonly subject not featuring the principals and credentials it's supposed to hold (note that LoginModuleImpl#credentials holds ImpersonationCredentials not to be found in the subject. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and the uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Description: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and then uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. was: LoginContextProviderImpl#getLoginContext(...) extracts the most recent subject from the AccessControlContext and the uses it for either a PreAuthContext or a JaasLoginContext. This is wrong, because there is no reason to assume that such a subject has anything to do with Oak. It particularly hurts when it's readonly, because JAAS will then silently fail to add principals and credentials. We would need a way to identify pre-authenticated subjects and subjects that are not pre-authenticated should not be used to create a JaasLoginContext. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8769) oak-auth-ldap pom needs maintenance
Manfred Baedke created OAK-8769: --- Summary: oak-auth-ldap pom needs maintenance Key: OAK-8769 URL: https://issues.apache.org/jira/browse/OAK-8769 Project: Jackrabbit Oak Issue Type: Bug Components: auth-ldap Reporter: Manfred Baedke The oak-auth-ldap pom features some legacy aspects that could use rework: * It defines a profile to disable certain tests for JDK1.6, which should be redundant now. * The defines a configuration for the maven-bundle-plugin which ** embeds dependencies, which might (at least for some) no longer be needed. ** embeds the dependencies transitively. Maybe we can get rid of that. ** has some obscure exclusions from the package imports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Description: The oak-auth-ldap pom features some legacy aspects that could use rework: * It defines a profile to disable certain tests for JDK1.6, which should be redundant now. * It defines a configuration for the maven-bundle-plugin which ** embeds dependencies, which might (at least for some) no longer be needed. ** embeds the dependencies transitively. Maybe we can get rid of that. ** has some obscure exclusions from the package imports. was: The oak-auth-ldap pom features some legacy aspects that could use rework: * It defines a profile to disable certain tests for JDK1.6, which should be redundant now. * The defines a configuration for the maven-bundle-plugin which ** embeds dependencies, which might (at least for some) no longer be needed. ** embeds the dependencies transitively. Maybe we can get rid of that. ** has some obscure exclusions from the package imports. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Priority: Minor > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Description: The oak-auth-ldap pom features some legacy aspects that could use rework: * It defines a profile to disable certain tests for JDK1.6, which should be redundant now. * It defines a configuration for the maven-bundle-plugin which ** embeds dependencies, which might (at least for some) no longer be needed. ** embeds the dependencies transitively. Maybe we can get rid of that. ** has some obscure exclusions from the package imports. Also, some of the dependencies use outdated versions. was: The oak-auth-ldap pom features some legacy aspects that could use rework: * It defines a profile to disable certain tests for JDK1.6, which should be redundant now. * It defines a configuration for the maven-bundle-plugin which ** embeds dependencies, which might (at least for some) no longer be needed. ** embeds the dependencies transitively. Maybe we can get rid of that. ** has some obscure exclusions from the package imports. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Priority: Minor > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke reassigned OAK-8769: --- Assignee: Manfred Baedke > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Attachment: OAK-8763.patch > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976649#comment-16976649 ] Manfred Baedke commented on OAK-8763: - See attached OAK-8763.patch for a change that fixes the issue mentioned in the previous comment. However, it still contains a TODO because I don't know how pre-authenticated subjects should be identified. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976678#comment-16976678 ] Manfred Baedke commented on OAK-8763: - [~angela], Note that this might be a security issue, since it looks like an anonymous login would give the consumer a PreAuthContext if there is a subject in the AccessControlContext. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978504#comment-16978504 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. i am not convinced that replacing a read-only subject by a new, writable one is really correct The patch is obviously not meant to be a final solution. The reasoning is that logout will return false in cases where it should return true. See https://issues.apache.org/jira/browse/OAK-8763?focusedCommentId=16973480&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16973480. I will add a test, but I'd really like to know your opinion on how to fix the problem. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978504#comment-16978504 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 3:16 PM: --- [~angela], bq. i am not convinced that replacing a read-only subject by a new, writable one is really correct The patch is obviously not meant to be a final solution. The reasoning is that logout will return false in cases where it should return true. See https://issues.apache.org/jira/browse/OAK-8763?focusedCommentId=16973480&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16973480. I will add a test, but I'd really like to know your opinion on how to fix the problem. If replacing a readonly subject is not correct, what would be correct instead? was (Author: baedke): [~angela], bq. i am not convinced that replacing a read-only subject by a new, writable one is really correct The patch is obviously not meant to be a final solution. The reasoning is that logout will return false in cases where it should return true. See https://issues.apache.org/jira/browse/OAK-8763?focusedCommentId=16973480&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16973480. I will add a test, but I'd really like to know your opinion on how to fix the problem. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978534#comment-16978534 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. if the logout is the problem, we should fix the logout not start modifying other pieces of the code base The logout fails because the login messes up the subject. Take a look https://github.com/apache/jackrabbit-oak/blob/80ad2ca1ec09b400d16b38476e107657e063117b/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/LoginContextProviderImpl.java#L77. The subject returned by #getSubject() was in the given case exactly the subject from the screenshot. It's readonly, so it will be used to create the JaasLoginContext. Later logout() doesn't know to handle it. If we can fix that without touching the login process, fine, but I don't see that. I'd really like to hear your thoughts. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978534#comment-16978534 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 3:50 PM: --- [~angela], bq. if the logout is the problem, we should fix the logout not start modifying other pieces of the code base The logout fails because the login messes up the subject. Take a look https://github.com/apache/jackrabbit-oak/blob/80ad2ca1ec09b400d16b38476e107657e063117b/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/LoginContextProviderImpl.java#L77. The subject returned by #getSubject() was in the given case exactly the subject from the screenshot. It's readonly, so it will be used to create the JaasLoginContext. Later logout() doesn't know to handle it. bq. if logout is the cuprit No, it's not. If we can fix that without touching the login process, fine, but I don't see that. I'd really like to hear your thoughts. was (Author: baedke): [~angela], bq. if the logout is the problem, we should fix the logout not start modifying other pieces of the code base The logout fails because the login messes up the subject. Take a look https://github.com/apache/jackrabbit-oak/blob/80ad2ca1ec09b400d16b38476e107657e063117b/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/LoginContextProviderImpl.java#L77. The subject returned by #getSubject() was in the given case exactly the subject from the screenshot. It's readonly, so it will be used to create the JaasLoginContext. Later logout() doesn't know to handle it. If we can fix that without touching the login process, fine, but I don't see that. I'd really like to hear your thoughts. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978534#comment-16978534 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 4:04 PM: --- [~angela], bq. if the logout is the problem, we should fix the logout not start modifying other pieces of the code base The logout fails because the login messes up the subject. Take a look https://github.com/apache/jackrabbit-oak/blob/80ad2ca1ec09b400d16b38476e107657e063117b/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/LoginContextProviderImpl.java#L77. The subject returned by #getSubject() was in the given case exactly the subject from the screenshot. It's readonly, so it will be used to create the LoginContext. Later logout() doesn't know to handle it. bq. if logout is the cuprit No, it's not. If we can fix that without touching the login process, fine, but I don't see that. I'd really like to hear your thoughts. was (Author: baedke): [~angela], bq. if the logout is the problem, we should fix the logout not start modifying other pieces of the code base The logout fails because the login messes up the subject. Take a look https://github.com/apache/jackrabbit-oak/blob/80ad2ca1ec09b400d16b38476e107657e063117b/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/LoginContextProviderImpl.java#L77. The subject returned by #getSubject() was in the given case exactly the subject from the screenshot. It's readonly, so it will be used to create the JaasLoginContext. Later logout() doesn't know to handle it. bq. if logout is the cuprit No, it's not. If we can fix that without touching the login process, fine, but I don't see that. I'd really like to hear your thoughts. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978576#comment-16978576 ] Manfred Baedke commented on OAK-8763: - [~angela], Re test case: Any idea how to create one testing the whole login/logout sequence without really creating an authenticated JMX connection are also welcome. The task is to make AccessController#getContext() return an AccessControlContext containing a given readonly subject. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978606#comment-16978606 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. ee also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978606#comment-16978606 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 5:10 PM: --- [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. see also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. was (Author: baedke): [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. ee also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978606#comment-16978606 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 5:14 PM: --- [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. see also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. If needed, it'd reproducible as communicated of Jira. I'd really like to learn what you think about it. was (Author: baedke): [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. see also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978606#comment-16978606 ] Manfred Baedke edited comment on OAK-8763 at 11/20/19 5:20 PM: --- [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. see also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. If needed, it'd reproducible as communicated off Jira. I'd really like to learn what you think about it. was (Author: baedke): [~angela], bq. i don't necessarily agree with your statement that the context provider messes up the subject upon login Call it whatever you like. It either doesn't use the correct subject or it doesn't use the subject correctly. bq. [0] http://jackrabbit.apache.org/oak/docs/security/authentication/preauthentication.html Thx, that looks about right. bq. see also OAK-8710 for some additional comments regarding reproducibility Well, maybe we can start discussing the issue even if it's not easily reproduced. If needed, it'd reproducible as communicated of Jira. I'd really like to learn what you think about it. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Attachment: OAK-8763-tests.patch > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Attachment: (was: OAK-8763-tests.patch) > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8763: Attachment: OAK-8763-tests.patch > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979352#comment-16979352 ] Manfred Baedke commented on OAK-8763: - [~angela], Please find attached two test cases. #testLoginLogoutPreexistingSubject() verifies that ContentSessionImpl#close() does not log an exception. #testLoginNullCredentialsPreexistingSubject() verifies that a login with null credentials will fail. Both tests will fail with the current trunk. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8710) AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
[
https://issues.apache.org/jira/browse/OAK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981510#comment-16981510
]
Manfred Baedke commented on OAK-8710:
-
[~angela],
bq. in particular i am wondering about the ImpersonationCredentials and the
fact that the impersonated user has the name of a system-user used for Adobe
AEM social... one reason why I am asking about this is the following:
service-user login with adobe AEM is not done with impersonation and does
neither use SimpleCredentials... so i am really not sure how you got there.
Good point. I'll see if I can forge a standalone test to reproduce that.
> AbstractLoginModule#logout() must not remove 'foreign' principals/credentials
> --
>
> Key: OAK-8710
> URL: https://issues.apache.org/jira/browse/OAK-8710
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: auth-external, core, security-spi
>Reporter: Manfred Baedke
>Assignee: Angela Schreiber
>Priority: Major
> Attachments: OAK-8710.patch, logout.png
>
>
> See
> https://github.com/apache/jackrabbit-oak/blob/9569d659f0655d3ba16c1cfe1fbb5f53959f701f/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/AbstractLoginModule.java#L189:
> The criterion for logout() to succeed is
> {code}!subject.getPrincipals().isEmpty() &&
> !subject.getPublicCredentials(Credentials.class).isEmpty(){code}
> This did not work in a case where the subject was created by a thread
> handling an authenticated JMX connection (and later passed on to other
> threads due to AccessControlContext inheritage).
> I'd propose to make logout() succeed unconditionally, but I'm not entirely
> sure about side effects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985013#comment-16985013 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. as far as the second test is concerned: this one essentially tests pre-auth login and must not fail IMO. So it's OK that one just needs an arbitrary subject that has never been authenticated to get a successful login? > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Major > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8151) Let ACE.getPrincipal return principals obtained from PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985145#comment-16985145
]
Manfred Baedke commented on OAK-8151:
-
1.10: http://svn.apache.org/viewvc?view=revision&revision=1870597
> Let ACE.getPrincipal return principals obtained from PrincipalManager
> -
>
> Key: OAK-8151
> URL: https://issues.apache.org/jira/browse/OAK-8151
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.12.0
>
> Attachments: OAK-8151.patch
>
>
> [~stillalex], while {{AccessControlEntry.getPrincipal}} does not mandate the
> that principal is actually obtained from {{PrincipalManager}} it turned out
> that some UI code actually relies on that implementation detail.
> we could still reduce the number of queries resulting from looking up
> principals by name, by making sure we don't read the same principal multiple
> times, while computing the entries for a given access control list. that
> might be somewhat of a compromise to reduce the number of lookups while
> returning the same principals as we did before optimizing the lookup in
> OAK-7880.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8151) Let ACE.getPrincipal return principals obtained from PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-8151:
Fix Version/s: 1.10.7
> Let ACE.getPrincipal return principals obtained from PrincipalManager
> -
>
> Key: OAK-8151
> URL: https://issues.apache.org/jira/browse/OAK-8151
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.12.0, 1.10.7
>
> Attachments: OAK-8151.patch
>
>
> [~stillalex], while {{AccessControlEntry.getPrincipal}} does not mandate the
> that principal is actually obtained from {{PrincipalManager}} it turned out
> that some UI code actually relies on that implementation detail.
> we could still reduce the number of queries resulting from looking up
> principals by name, by making sure we don't read the same principal multiple
> times, while computing the entries for a given access control list. that
> might be somewhat of a compromise to reduce the number of lookups while
> returning the same principals as we did before optimizing the lookup in
> OAK-7880.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8151) Let ACE.getPrincipal return principals obtained from PrincipalManager
[
https://issues.apache.org/jira/browse/OAK-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-8151:
Labels: (was: candidate_oak_1_10)
> Let ACE.getPrincipal return principals obtained from PrincipalManager
> -
>
> Key: OAK-8151
> URL: https://issues.apache.org/jira/browse/OAK-8151
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Minor
> Fix For: 1.12.0
>
> Attachments: OAK-8151.patch
>
>
> [~stillalex], while {{AccessControlEntry.getPrincipal}} does not mandate the
> that principal is actually obtained from {{PrincipalManager}} it turned out
> that some UI code actually relies on that implementation detail.
> we could still reduce the number of queries resulting from looking up
> principals by name, by making sure we don't read the same principal multiple
> times, while computing the entries for a given access control list. that
> might be somewhat of a compromise to reduce the number of lookups while
> returning the same principals as we did before optimizing the lookup in
> OAK-7880.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8798) Upgrade maven-bundle-plugin to 4.2.1
[
https://issues.apache.org/jira/browse/OAK-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987186#comment-16987186
]
Manfred Baedke commented on OAK-8798:
-
[~reschke],
The following plugin config worked for me:
{code}
org.apache.felix
maven-bundle-plugin
4.2.1
${guava.osgi.import},
org.apache.lucene.*;resolution:=optional,
com.googlecode.*;resolution:=optional,
com.vividsolutions.jts.*;resolution:=optional,
com.sun.*;resolution:=optional,
jline;resolution:=optional,
org.apache.hadoop.*;resolution:=optional,
org.apache.regexp.*;resolution:=optional,
org.apache.log4j.*;resolution:=optional,
org.jboss.netty.*;resolution:=optional,
org.restlet.*;resolution:=optional,
org.joda.time.*;resolution:=optional,
org.eclipse.*;resolution:=optional,
javax.servlet.*;resolution:=optional,
com.tdunning.math.*;resolution:=optional,
com.codahale.metrics.*;resolution:=optional,
info.ganglia.gmetric4j.*;resolution:=optional,
org.apache.calcite.adapter.*;resolution:=optional,
org.apache.calcite.ling4j.*;resolution:=optional,
org.apache.calcite.rel.*;resolution:=optional,
org.apache.calcite.schema.*;resolution:=optional,
org.apache.calcite.sql.*;resolution:=optional,
org.apache.calcite.*;resolution:=optional,
org.apache.curator.framework.*;resolution:=optional,
org.apache.curator.*;resolution:=optional,
com.github.benmanes.caffeine.*;resolution:=optional,
com.ibm.security.krb5.internal.*;resolution:=optional,
org.apache.solr.handler.extraction.*;resolution:=optional,
sun.misc.*;resolution:=optional,
sun.security.krb5.*;resolution:=optional,
*
*;scope=runtime;inline=true
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.SolrQueryIndexProviderService.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.SolrServerProviderService.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.SolrIndexEditorProviderService.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.EmbeddedSolrServerConfigurationProvider.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.RemoteSolrServerConfigurationProvider.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.OakSolrConfigurationProviderService.xml,
OSGI-INF/org.apache.jackrabbit.oak.plugins.index.solr.osgi.NodeStateSolrServersObserverService.xml
{code}
While I don't know why version 4.2.1 finds these additional dependencies, I
think it's safe to include them as optional (at least it seems safer than
excluding them).
> Upgrade maven-bundle-plugin to 4.2.1
>
>
> Key: OAK-8798
> URL: https://issues.apache.org/jira/browse/OAK-8798
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.22.0
>
> Attachments: OAK-8798.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987895#comment-16987895 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. IMO the repository must not mandate how a pre-authenticated subject is generated Agreed, but I don't know if the issue is completely solved. Note that the incoming subject is readonly, so we will fail to add any credentials or principals on login. I would expect that to cause authorization issues, but did not verify. I guess you can tell immediately. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Minor > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988058#comment-16988058 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. this issue as you reported it is only about the failing logout. so please let me know if that part is fixed in the environment your have been testing That was another issue , but yes, these tests no longer fail. This issue not about logout. Let me quote from the description: bq. because JAAS will then silently fail to add principals and credentials. That's still my concern. bq. if an application passes a read-only subject, the session will get the permissions defined for the specified principals. You mean the principals found in the readonly subject? > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Minor > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988058#comment-16988058 ] Manfred Baedke edited comment on OAK-8763 at 12/4/19 6:12 PM: -- [~angela], bq. this issue as you reported it is only about the failing logout. so please let me know if that part is fixed in the environment your have been testing That was another issue , but yes, these tests no longer fail. This issue is not about logout. Let me quote from the description: bq. because JAAS will then silently fail to add principals and credentials. That's still my concern. bq. if an application passes a read-only subject, the session will get the permissions defined for the specified principals. You mean the principals found in the readonly subject? was (Author: baedke): [~angela], bq. this issue as you reported it is only about the failing logout. so please let me know if that part is fixed in the environment your have been testing That was another issue , but yes, these tests no longer fail. This issue not about logout. Let me quote from the description: bq. because JAAS will then silently fail to add principals and credentials. That's still my concern. bq. if an application passes a read-only subject, the session will get the permissions defined for the specified principals. You mean the principals found in the readonly subject? > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Minor > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8763) LoginContextProviderImpl uses any subject found in the AccessControlContext.
[ https://issues.apache.org/jira/browse/OAK-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16989043#comment-16989043 ] Manfred Baedke commented on OAK-8763: - [~angela], bq. i got confused, which of the 2 issues you were posting to because the discussions kept getting mixed Yes, I noticed. bq. yes, i mean the principals from the read-only subject. Which means, in the case of the original scenario, some "JMXPrincipal: xyz", which is then the only principal to be found in the context. No principal associated with the user logging in will be contained in there. To me that looks like authorization issues. > LoginContextProviderImpl uses any subject found in the AccessControlContext. > > > Key: OAK-8763 > URL: https://issues.apache.org/jira/browse/OAK-8763 > Project: Jackrabbit Oak > Issue Type: Bug > Components: security-spi >Reporter: Manfred Baedke >Assignee: Angela Schreiber >Priority: Minor > Attachments: OAK-8763-tests.patch, OAK-8763.patch > > > LoginContextProviderImpl#getLoginContext(...) extracts the most recent > subject from the AccessControlContext and then uses it for either a > PreAuthContext or a JaasLoginContext. This is wrong, because there is no > reason to assume that such a subject has anything to do with Oak. It > particularly hurts when it's readonly, because JAAS will then silently fail > to add principals and credentials. > We would need a way to identify pre-authenticated subjects and subjects that > are not pre-authenticated should not be used to create a JaasLoginContext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012030#comment-17012030 ] Manfred Baedke commented on OAK-8769: - I ambitiously tried to update to api-all-2.0.0. Since there are incompatiblle changes vs api-all-1.00, some code changes were required, but even then we can't run the tests, because they start an internal LDAP server using the artifact org.apache.directory.server.apacheds-core, which depends on api-all-1.0.0 (even the most recent versions). So in order to switch to api-all-2.0.0, we'd have to use a different LDAP server for testing (or maybe do some forking magic). > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012030#comment-17012030 ] Manfred Baedke edited comment on OAK-8769 at 1/9/20 4:42 PM: - I ambitiously tried to update to api-all-2.0.0. Since there are incompatible changes vs api-all-1.00, some code changes were required, but even then we can't run the tests, because they start an internal LDAP server using the artifact org.apache.directory.server.apacheds-core, which depends on api-all-1.0.0 (even the most recent versions). So in order to switch to api-all-2.0.0, we'd have to use a different LDAP server for testing (or maybe do some forking magic). was (Author: baedke): I ambitiously tried to update to api-all-2.0.0. Since there are incompatiblle changes vs api-all-1.00, some code changes were required, but even then we can't run the tests, because they start an internal LDAP server using the artifact org.apache.directory.server.apacheds-core, which depends on api-all-1.0.0 (even the most recent versions). So in order to switch to api-all-2.0.0, we'd have to use a different LDAP server for testing (or maybe do some forking magic). > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-2832) Test failure: DefaultAnalyzersConfigurationTest
[
https://issues.apache.org/jira/browse/OAK-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-2832:
Attachment: jackrabbit-oak-1.10.8.log
> Test failure: DefaultAnalyzersConfigurationTest
> ---
>
> Key: OAK-2832
> URL: https://issues.apache.org/jira/browse/OAK-2832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: CI, jenkins
> Fix For: 1.2.3, 1.3.0, 1.4
>
> Attachments: OAK-2832.patch, jackrabbit-oak-1.10.8.log
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest.org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest}}
> fails on Jenkins.
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/123/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=unittesting/console
> Seen on {{DOCUMENT_RDB}} and {{SEGMENT_MK}} with Java 1.7. and 1.8.
> {noformat}
> Tests run: 13, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.572 sec
> <<< FAILURE!
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest
> Time elapsed: 23.255 sec <<< ERROR!
> com.carrotsearch.randomizedtesting.ThreadLeakError: 21 threads leaked from
> SUITE scope at
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest:
>
>1) Thread[id=32, name=oak-scheduled-executor-13, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>2) Thread[id=25, name=oak-scheduled-executor-6, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-2832) Test failure: DefaultAnalyzersConfigurationTest
[
https://issues.apache.org/jira/browse/OAK-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025178#comment-17025178
]
Manfred Baedke commented on OAK-2832:
-
Still seems to be an issue, see attached jackrabbit-oak-1.10.8.log (from the
release check).
> Test failure: DefaultAnalyzersConfigurationTest
> ---
>
> Key: OAK-2832
> URL: https://issues.apache.org/jira/browse/OAK-2832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: CI, jenkins
> Fix For: 1.2.3, 1.3.0, 1.4
>
> Attachments: OAK-2832.patch, jackrabbit-oak-1.10.8.log
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest.org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest}}
> fails on Jenkins.
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/123/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=unittesting/console
> Seen on {{DOCUMENT_RDB}} and {{SEGMENT_MK}} with Java 1.7. and 1.8.
> {noformat}
> Tests run: 13, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.572 sec
> <<< FAILURE!
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest
> Time elapsed: 23.255 sec <<< ERROR!
> com.carrotsearch.randomizedtesting.ThreadLeakError: 21 threads leaked from
> SUITE scope at
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest:
>
>1) Thread[id=32, name=oak-scheduled-executor-13, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>2) Thread[id=25, name=oak-scheduled-executor-6, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-2832) Test failure: DefaultAnalyzersConfigurationTest
[
https://issues.apache.org/jira/browse/OAK-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025178#comment-17025178
]
Manfred Baedke edited comment on OAK-2832 at 1/28/20 2:50 PM:
--
Still seems to be an issue, see attached jackrabbit-oak-1.10.8.log (from the
release check).
cc [~mreutegg], [~mduerig]
was (Author: baedke):
Still seems to be an issue, see attached jackrabbit-oak-1.10.8.log (from the
release check).
> Test failure: DefaultAnalyzersConfigurationTest
> ---
>
> Key: OAK-2832
> URL: https://issues.apache.org/jira/browse/OAK-2832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: CI, jenkins
> Fix For: 1.2.3, 1.3.0, 1.4
>
> Attachments: OAK-2832.patch, jackrabbit-oak-1.10.8.log
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest.org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest}}
> fails on Jenkins.
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/123/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=unittesting/console
> Seen on {{DOCUMENT_RDB}} and {{SEGMENT_MK}} with Java 1.7. and 1.8.
> {noformat}
> Tests run: 13, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.572 sec
> <<< FAILURE!
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest
> Time elapsed: 23.255 sec <<< ERROR!
> com.carrotsearch.randomizedtesting.ThreadLeakError: 21 threads leaked from
> SUITE scope at
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest:
>
>1) Thread[id=32, name=oak-scheduled-executor-13, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>2) Thread[id=25, name=oak-scheduled-executor-6, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (OAK-2832) Test failure: DefaultAnalyzersConfigurationTest
[
https://issues.apache.org/jira/browse/OAK-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-2832:
Comment: was deleted
(was: Still seems to be an issue, see attached jackrabbit-oak-1.10.8.log (from
the release check).
cc [~mreutegg], [~mduerig])
> Test failure: DefaultAnalyzersConfigurationTest
> ---
>
> Key: OAK-2832
> URL: https://issues.apache.org/jira/browse/OAK-2832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: CI, jenkins
> Fix For: 1.2.3, 1.3.0, 1.4
>
> Attachments: OAK-2832.patch
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest.org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest}}
> fails on Jenkins.
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/123/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=unittesting/console
> Seen on {{DOCUMENT_RDB}} and {{SEGMENT_MK}} with Java 1.7. and 1.8.
> {noformat}
> Tests run: 13, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.572 sec
> <<< FAILURE!
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest
> Time elapsed: 23.255 sec <<< ERROR!
> com.carrotsearch.randomizedtesting.ThreadLeakError: 21 threads leaked from
> SUITE scope at
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest:
>
>1) Thread[id=32, name=oak-scheduled-executor-13, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>2) Thread[id=25, name=oak-scheduled-executor-6, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-2832) Test failure: DefaultAnalyzersConfigurationTest
[
https://issues.apache.org/jira/browse/OAK-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-2832:
Attachment: (was: jackrabbit-oak-1.10.8.log)
> Test failure: DefaultAnalyzersConfigurationTest
> ---
>
> Key: OAK-2832
> URL: https://issues.apache.org/jira/browse/OAK-2832
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Labels: CI, jenkins
> Fix For: 1.2.3, 1.3.0, 1.4
>
> Attachments: OAK-2832.patch
>
>
> {{org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest.org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest}}
> fails on Jenkins.
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/123/jdk=latest1.7,label=Ubuntu,nsfixtures=SEGMENT_MK,profile=unittesting/console
> Seen on {{DOCUMENT_RDB}} and {{SEGMENT_MK}} with Java 1.7. and 1.8.
> {noformat}
> Tests run: 13, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.572 sec
> <<< FAILURE!
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest
> Time elapsed: 23.255 sec <<< ERROR!
> com.carrotsearch.randomizedtesting.ThreadLeakError: 21 threads leaked from
> SUITE scope at
> org.apache.jackrabbit.oak.plugins.index.solr.configuration.DefaultAnalyzersConfigurationTest:
>
>1) Thread[id=32, name=oak-scheduled-executor-13, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>2) Thread[id=25, name=oak-scheduled-executor-6, state=TIMED_WAITING,
> group=main]
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1125)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:807)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
Manfred Baedke created OAK-8890: --- Summary: LDAP login may fail if a server or intermediate silently drops connections Key: OAK-8890 URL: https://issues.apache.org/jira/browse/OAK-8890 Project: Jackrabbit Oak Issue Type: Bug Components: auth-ldap Reporter: Manfred Baedke Assignee: Manfred Baedke This has been seen on production systems with Oak 1.10.2, where a firewall was configured to drop idle connections after a timeout without sending an RST (for security reasons). When this happens, the connection pool used by the LdapPrincipalProvider will still consider these connections healthy. Eventually such a connection will be used for an actual LDAP BIND/SEARCH, which will simply timeout. The connection pool is an instance of org.apache.commons.pool.impl.GenericObjectPool, which has configuration options to deal with the scenario (namely running an eviction task which will properly close idle connections after a timeout which is shorter than the timeout interval used by the firewall) . The creation of the connection pool used is hard coded and most of the configuration options are not available. I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030881#comment-17030881 ] Manfred Baedke commented on OAK-8890: - It wouldn't be a good idea to expose every available config option (see https://commons.apache.org/proper/commons-pool/api-2.8.0/index.html), since these are implementation details of apache.commons.pool2. Currently exactly one of these options is configurable, namely the pool size. To fix the issue at hand, we'd need a background job evicting idle connections after a configurable timeout interval. The default implementation (https://commons.apache.org/proper/commons-pool/api-2.8.0/org/apache/commons/pool2/impl/DefaultEvictionPolicy.html) has such an option, which is disabled by default. I'd go for the simplest solution and offer two additional config option allowing to set the time between two eviction runs and the minimum idle time after which a connection shall be evicted. A patch will follow tomorrow. > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030881#comment-17030881 ] Manfred Baedke edited comment on OAK-8890 at 2/5/20 5:59 PM: - It wouldn't be a good idea to expose every available config option (see https://commons.apache.org/proper/commons-pool/api-2.8.0/index.html), since these are implementation details of apache.commons.pool2. Currently exactly one of these options is configurable, namely the pool size. To fix the issue at hand, we'd need a background job evicting idle connections after a configurable timeout interval. The default implementation (https://commons.apache.org/proper/commons-pool/api-2.8.0/org/apache/commons/pool2/impl/DefaultEvictionPolicy.html) has such an option, which is disabled by default. I'd go for the simplest solution and offer two additional config options allowing to set the time between two eviction runs and the minimum idle time after which a connection shall be evicted. A patch will follow tomorrow. was (Author: baedke): It wouldn't be a good idea to expose every available config option (see https://commons.apache.org/proper/commons-pool/api-2.8.0/index.html), since these are implementation details of apache.commons.pool2. Currently exactly one of these options is configurable, namely the pool size. To fix the issue at hand, we'd need a background job evicting idle connections after a configurable timeout interval. The default implementation (https://commons.apache.org/proper/commons-pool/api-2.8.0/org/apache/commons/pool2/impl/DefaultEvictionPolicy.html) has such an option, which is disabled by default. I'd go for the simplest solution and offer two additional config option allowing to set the time between two eviction runs and the minimum idle time after which a connection shall be evicted. A patch will follow tomorrow. > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8901) The oak-run command checkpoints doesn't support RDBDocumentStore
Manfred Baedke created OAK-8901: --- Summary: The oak-run command checkpoints doesn't support RDBDocumentStore Key: OAK-8901 URL: https://issues.apache.org/jira/browse/OAK-8901 Project: Jackrabbit Oak Issue Type: Improvement Components: run Reporter: Manfred Baedke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8901) The oak-run command checkpoints doesn't support RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8901: Attachment: OAK-8901.patch > The oak-run command checkpoints doesn't support RDBDocumentStore > > > Key: OAK-8901 > URL: https://issues.apache.org/jira/browse/OAK-8901 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Manfred Baedke >Priority: Major > Attachments: OAK-8901.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8901) The oak-run command checkpoints doesn't support RDBDocumentStore
[ https://issues.apache.org/jira/browse/OAK-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17036278#comment-17036278 ] Manfred Baedke commented on OAK-8901: - [~reschke], So attached OAK-8901.patch. > The oak-run command checkpoints doesn't support RDBDocumentStore > > > Key: OAK-8901 > URL: https://issues.apache.org/jira/browse/OAK-8901 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: run >Reporter: Manfred Baedke >Priority: Major > Attachments: OAK-8901.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8890: Attachment: OAK-8890.patch > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Attachments: OAK-8890.patch > > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8890: Attachment: (was: OAK-8890.patch) > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Attachments: OAK-8890.patch > > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8890: Attachment: OAK-8890.patch > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Attachments: OAK-8890.patch > > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8890) LDAP login may fail if a server or intermediate silently drops connections
[ https://issues.apache.org/jira/browse/OAK-8890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060331#comment-17060331 ] Manfred Baedke commented on OAK-8890: - Updated patch with missing documentation. > LDAP login may fail if a server or intermediate silently drops connections > -- > > Key: OAK-8890 > URL: https://issues.apache.org/jira/browse/OAK-8890 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Attachments: OAK-8890.patch > > > This has been seen on production systems with Oak 1.10.2, where a firewall > was configured to drop idle connections after a timeout without sending an > RST (for security reasons). When this happens, the connection pool used by > the LdapPrincipalProvider will still consider these connections healthy. > Eventually such a connection will be used for an actual LDAP BIND/SEARCH, > which will simply timeout. > The connection pool is an instance of > org.apache.commons.pool.impl.GenericObjectPool, which has configuration > options to deal with the scenario (namely running an eviction task which will > properly close idle connections after a timeout which is shorter than the > timeout interval used by the firewall) . > The creation of the connection pool used is hard coded and most of the > configuration options are not available. > I propose to change that. I'll supply a patch soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066696#comment-17066696 ] Manfred Baedke commented on OAK-8769: - Attached OAK-8769.patch. Summary of changes: * removed test exclusions for Java 1.6 * Updated to org.apache.directory.api.api-all-2.0.0 (LDAP client API). That implies some minor code modifications because of incompatible API changes. * Updated to org.apache.directory.server.apacheds-all-2.0.0-M24 (LDAP server used for testing). Unfortunately, this still uses older incompatible versions of some dependencies. Therefore the tests have been modified to use a separate ClassLoader to start and set up the server. * Jacoco now measures a slightly lower coverage, though we run the same test set. I'll look into that. For the attached patch I adjusted the expectations. * disabled transitive embedding of the dependencies. That is probably not a good idea, I will do some tests. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066696#comment-17066696 ] Manfred Baedke edited comment on OAK-8769 at 3/25/20, 2:41 PM: --- Attached OAK-8769.patch. Summary of changes: * removed test exclusions for Java 1.6 * Updated to org.apache.directory.api.api-all-2.0.0 (LDAP client API). That implies some minor code modifications because of incompatible API changes. * Updated to org.apache.directory.server.apacheds-all-2.0.0-M24 (LDAP server used for testing). Unfortunately, this still uses older incompatible versions of some dependencies. Therefore the tests have been modified to use a separate ClassLoader to start and set up the server. * Jacoco now measures a slightly lower coverage, though we run the same test set. I'll look into that (probably it's caused by the additional reflection we have to use now). For the attached patch I adjusted the expectations. * disabled transitive embedding of the dependencies. That is probably not a good idea, I will do some tests. was (Author: baedke): Attached OAK-8769.patch. Summary of changes: * removed test exclusions for Java 1.6 * Updated to org.apache.directory.api.api-all-2.0.0 (LDAP client API). That implies some minor code modifications because of incompatible API changes. * Updated to org.apache.directory.server.apacheds-all-2.0.0-M24 (LDAP server used for testing). Unfortunately, this still uses older incompatible versions of some dependencies. Therefore the tests have been modified to use a separate ClassLoader to start and set up the server. * Jacoco now measures a slightly lower coverage, though we run the same test set. I'll look into that. For the attached patch I adjusted the expectations. * disabled transitive embedding of the dependencies. That is probably not a good idea, I will do some tests. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-2.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: (was: OAK-8769-2.patch) > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-2.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072878#comment-17072878 ] Manfred Baedke commented on OAK-8769: - Attached OAK-8769-2.patch, fixing dependencies and imports. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: (was: OAK-8769-2.patch) > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-2.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073848#comment-17073848 ] Manfred Baedke commented on OAK-8769: - Attached new version of OAK-8769-2.patch, adding a license header and embedded runtime dependencies. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17073849#comment-17073849 ] Manfred Baedke commented on OAK-8769: - [~reschke], [~angela], you might want to review this. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-dep-updates.diff, > OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-osgi-it.
Manfred Baedke created OAK-8993: --- Summary: oak-auth-external and oak-auth-ldap are not covered by oak-osgi-it. Key: OAK-8993 URL: https://issues.apache.org/jira/browse/OAK-8993 Project: Jackrabbit Oak Issue Type: Test Components: osgi Reporter: Manfred Baedke Assignee: Manfred Baedke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-osgi-it.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8993: Issue Type: Task (was: Test) > oak-auth-external and oak-auth-ldap are not covered by oak-osgi-it. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-3.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074753#comment-17074753 ] Manfred Baedke commented on OAK-8769: - Attached OAK-8769-3.patch, embedding commons-collections4 which no other Oak bundle depends on. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17074753#comment-17074753 ] Manfred Baedke edited comment on OAK-8769 at 4/3/20, 5:40 PM: -- Attached OAK-8769-3.patch (applicable from the directory oak-auth-ldap) , embedding commons-collections4 which no other Oak bundle depends on. was (Author: baedke): Attached OAK-8769-3.patch, embedding commons-collections4 which no other Oak bundle depends on. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8993: Summary: oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. (was: oak-auth-external and oak-auth-ldap are not covered by oak-osgi-it.) > oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8993: Attachment: OAK-8993.patch > oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8993.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8769: Attachment: OAK-8769-4.patch > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, OAK-8769-4.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078391#comment-17078391 ] Manfred Baedke edited comment on OAK-8769 at 4/8/20, 3:34 PM: -- Attached OAK-8769-4.patch. commons-collections4 is no longer embedded and a bug with paged LDAP searches is fixed. was (Author: baedke): Attached OAK-8679-4.patch. commons-collections4 is no longer embedded and a bug with paged LDAP searches is fixed. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, OAK-8769-4.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8769) oak-auth-ldap pom needs maintenance
[ https://issues.apache.org/jira/browse/OAK-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078391#comment-17078391 ] Manfred Baedke commented on OAK-8769: - Attached OAK-8679-4.patch. commons-collections4 is no longer embedded and a bug with paged LDAP searches is fixed. > oak-auth-ldap pom needs maintenance > --- > > Key: OAK-8769 > URL: https://issues.apache.org/jira/browse/OAK-8769 > Project: Jackrabbit Oak > Issue Type: Bug > Components: auth-ldap >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > Attachments: OAK-8769-2.patch, OAK-8769-3.patch, OAK-8769-4.patch, > OAK-8769-dep-updates.diff, OAK-8769.patch > > > The oak-auth-ldap pom features some legacy aspects that could use rework: > * It defines a profile to disable certain tests for JDK1.6, which should be > redundant now. > * It defines a configuration for the maven-bundle-plugin which > ** embeds dependencies, which might (at least for some) no longer be needed. > ** embeds the dependencies transitively. Maybe we can get rid of that. > ** has some obscure exclusions from the package imports. > Also, some of the dependencies use outdated versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-8993: Attachment: (was: OAK-8993.patch) > oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved OAK-8993. - Resolution: Done > oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8993) oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi.
[ https://issues.apache.org/jira/browse/OAK-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17079377#comment-17079377 ] Manfred Baedke commented on OAK-8993: - http://svn.apache.org/viewvc?view=revision&revision=1876325 > oak-auth-external and oak-auth-ldap are not covered by oak-it-osgi. > --- > > Key: OAK-8993 > URL: https://issues.apache.org/jira/browse/OAK-8993 > Project: Jackrabbit Oak > Issue Type: Task > Components: osgi >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
