[jira] [Comment Edited] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100190#comment-17100190
]
Manfred Baedke edited comment on OAK-9024 at 5/5/20, 7:12 PM:
--
[~jsedding], I think we understand the root cause, see
https://issues.apache.org/jira/browse/OAK-9024?focusedCommentId=17089747&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17089747
Note that IIUC embedding dependencies of oak-solr-core is one of the points of
oak-solr-osgi.
was (Author: baedke):
[~jsedding], I think we understand the root cause, see
https://issues.apache.org/jira/browse/OAK-9024?focusedCommentId=17089747&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17089747
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9024) oak-solr-osgi imports org.slf4j.impl
[
https://issues.apache.org/jira/browse/OAK-9024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100190#comment-17100190
]
Manfred Baedke commented on OAK-9024:
-
[~jsedding], I think we understand the root cause, see
https://issues.apache.org/jira/browse/OAK-9024?focusedCommentId=17089747&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17089747
> oak-solr-osgi imports org.slf4j.impl
>
>
> Key: OAK-9024
> URL: https://issues.apache.org/jira/browse/OAK-9024
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: solr
>Reporter: Julian Reschke
>Assignee: Manfred Baedke
>Priority: Minor
> Fix For: 1.28.0
>
> Attachments: OAK-9024.patch
>
>
> From the manifest:
> {{org.slf4j.impl;version="[1.6,2)"}}
--
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=17100167#comment-17100167 ] Manfred Baedke commented on OAK-8890: - Updated patch: changed input format, added unit tests. > 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 > > 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] [Assigned] (OAK-9052) Reindexing using --doc-traversal-mode may need a lot of memory
[ https://issues.apache.org/jira/browse/OAK-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-9052: --- Assignee: Thomas Mueller > Reindexing using --doc-traversal-mode may need a lot of memory > -- > > Key: OAK-9052 > URL: https://issues.apache.org/jira/browse/OAK-9052 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, mongomk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Major > > Indexing using oak-run and --doc-traversal-mode uses the FlatFileStore. For > aggregation, there is a limit on memory usage, by default around 100 MB. > Depending on the content structure, this limit can be exceeded. > It would be good to find a way to avoid a memory limit, for example using a > temporary storage (a file, or a persistent key/value store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-9052) Reindexing using --doc-traversal-mode may need a lot of memory
[ https://issues.apache.org/jira/browse/OAK-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099871#comment-17099871 ] Thomas Mueller commented on OAK-9052: - Data structure: * FlatFileBufferLinkedList is used in the second phase and contains a list of NodeStateEntry objects. * NodeStateEntry.nodeState is a LazyChildrenNodeState for entries in memory, but can be a DocumentNodeState when reading from MongoDB (in the first phase). * NodeStateEntry objects can be (de-)serialized using the NodeStateEntryWriter / NodeStateEntryReader. That is usually only used in the first phase. * The temp file is stored in temp/flat-file-store/sort-work-dir/sortInBatch...flatfile (by default using compression). > Reindexing using --doc-traversal-mode may need a lot of memory > -- > > Key: OAK-9052 > URL: https://issues.apache.org/jira/browse/OAK-9052 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing, mongomk >Reporter: Thomas Mueller >Priority: Major > > Indexing using oak-run and --doc-traversal-mode uses the FlatFileStore. For > aggregation, there is a limit on memory usage, by default around 100 MB. > Depending on the content structure, this limit can be exceeded. > It would be good to find a way to avoid a memory limit, for example using a > temporary storage (a file, or a persistent key/value store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9052) Reindexing using --doc-traversal-mode may need a lot of memory
Thomas Mueller created OAK-9052: --- Summary: Reindexing using --doc-traversal-mode may need a lot of memory Key: OAK-9052 URL: https://issues.apache.org/jira/browse/OAK-9052 Project: Jackrabbit Oak Issue Type: Improvement Components: indexing, mongomk Reporter: Thomas Mueller Indexing using oak-run and --doc-traversal-mode uses the FlatFileStore. For aggregation, there is a limit on memory usage, by default around 100 MB. Depending on the content structure, this limit can be exceeded. It would be good to find a way to avoid a memory limit, for example using a temporary storage (a file, or a persistent key/value store). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration
[
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099855#comment-17099855
]
Julian Sedding edited comment on OAK-9047 at 5/5/20, 1:06 PM:
--
{quote}[...] that's why Francesco Mari introduced the
SecurityProviderRegistration and the mandatory services in the first place.
{quote}
That seems to be a variation of the same problem discussed in this issue. The
constituent services for a functioning repository must not become available
before they are properly configured. This is inherently difficult to achieve in
OSGi.
I wonder if a better strategy to address this would be de-modularisation of the
repository startup, i.e. have a single required configuration and hook all
parts together in plain Java before registering the repository.
Clearly there is a trade-off between a stable repository startup sequence some
disadvantages, e.g. backwards compatibility with current configurations and
substituting a custom implementations for some components would not work/would
need to be done differently.
Maybe a possibility could be a repository factory service that is used by a
repository registration service. The repository registration service could be
configured to require a specific repository factory and, once available, would
call it to get a repository instance and register it. Repository factory
implementations could require a configuration to prevent eager startup or be
manually registered after checking a number of requirements, thus making sure
everything is properly available before a repository is created (similar to
SecurityProviderRegistration does today). The current status quo could become
the default implementation for the repository factory (without required
configuration). However, another factory could then use stricter checks.
{quote}[We can solve any problem by introducing an extra level of
indirection.|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering]
{quote}
On a somewhat related note: (at least in AEM) the NodeStore service is
currently explicitly hidden, which makes sense, because it is an implementation
detail. Registering the NodeStore as a service would not be required at all
with a suitable repository factory. Maybe the desire to hide this service is an
indication that the OSGi service registry is the wrong place to hook all parts
together?
was (Author: jsedding):
bq. [...] that's why Francesco Mari introduced the SecurityProviderRegistration
and the mandatory services in the first place.
That seems to be a variation of the same problem discussed in this issue. The
constituent services for a functioning repository must not become available
before they are properly configured. This is inherently difficult to achieve in
OSGi.
I wonder if a better strategy to address this would be de-modularisation of the
repository startup, i.e. have a single required configuration and hook all
parts together in plain Java before registering the repository.
Clearly there is a trade-off between a stable repository startup sequence some
disadvantages, e.g. backwards compatibility with current configurations and
substituting a custom implementations for some components would not work/would
need to be done differently.
Maybe a possibility could be a repository factory service that is used by a
repository registration service. The repository registration service could be
configured to require a specific repository factory and, once available, would
call it to get a repository instance and register it. Repository factory
implementations could require a configuration to prevent eager startup or be
manually registered after checking a number of requirements, thus making sure
everything is properly available before a repository is created (similar to
SecurityProviderRegistration does today). The current status quo could become
the default implementation for the repository factory (without required
configuration). However, another factory could then use stricter checks.
bq. [We can solve any problem by introducing an extra level of
indirection.|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering]
> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to
> restart of the Oak repository in the context of
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171&page=com.atlassian.jira.plugin.system.issuetabpa
[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration
[
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099855#comment-17099855
]
Julian Sedding commented on OAK-9047:
-
bq. [...] that's why Francesco Mari introduced the SecurityProviderRegistration
and the mandatory services in the first place.
That seems to be a variation of the same problem discussed in this issue. The
constituent services for a functioning repository must not become available
before they are properly configured. This is inherently difficult to achieve in
OSGi.
I wonder if a better strategy to address this would be de-modularisation of the
repository startup, i.e. have a single required configuration and hook all
parts together in plain Java before registering the repository.
Clearly there is a trade-off between a stable repository startup sequence some
disadvantages, e.g. backwards compatibility with current configurations and
substituting a custom implementations for some components would not work/would
need to be done differently.
Maybe a possibility could be a repository factory service that is used by a
repository registration service. The repository registration service could be
configured to require a specific repository factory and, once available, would
call it to get a repository instance and register it. Repository factory
implementations could require a configuration to prevent eager startup or be
manually registered after checking a number of requirements, thus making sure
everything is properly available before a repository is created (similar to
SecurityProviderRegistration does today). The current status quo could become
the default implementation for the repository factory (without required
configuration). However, another factory could then use stricter checks.
bq. [We can solve any problem by introducing an extra level of
indirection.|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering]
> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to
> restart of the Oak repository in the context of
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>
> It would make sense to only start the service
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
> once a mandatory configuration is in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9041) Build Jackrabbit Oak #2732 failed
[ https://issues.apache.org/jira/browse/OAK-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099762#comment-17099762 ] Hudson commented on OAK-9041: - Build is still failing. Failed run: [Jackrabbit Oak #2739|https://builds.apache.org/job/Jackrabbit%20Oak/2739/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2739/console] > Build Jackrabbit Oak #2732 failed > - > > Key: OAK-9041 > URL: https://issues.apache.org/jira/browse/OAK-9041 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2732 has failed. > First failed run: [Jackrabbit Oak > #2732|https://builds.apache.org/job/Jackrabbit%20Oak/2732/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2732/console] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-9046.
-
Resolution: Fixed
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.28.0
>
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099667#comment-17099667
]
Thomas Mueller commented on OAK-9046:
-
http://svn.apache.org/r1877376
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.28.0
>
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9046) Index function string-length should index size for binary properties
[
https://issues.apache.org/jira/browse/OAK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-9046:
Fix Version/s: 1.28.0
> Index function string-length should index size for binary properties
>
>
> Key: OAK-9046
> URL: https://issues.apache.org/jira/browse/OAK-9046
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.28.0
>
>
> For index definition
> {noformat}
> jcr:primaryType="nt:unstructured"
> ordered="{Boolean}true"
> propertyIndex="{Boolean}true"
> type="Long"
> function="fn:string-length(jcr:content/@jcr:data)"/>
> {noformat}
> Expected result: Index the size of @jcr:data
> Current result:
> {noformat}
> ERROR o.a.j.o.p.i.l.LuceneDocumentMaker - Failed to calculate function value
> for [function, length, @jcr:content/jcr:data] ...
> java.lang.IllegalStateException: String is too long: 2325601444581057974
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-9051) Enhance oak-exercise for Principal base authorization
[ https://issues.apache.org/jira/browse/OAK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber reassigned OAK-9051: - Assignee: Angela Schreiber > Enhance oak-exercise for Principal base authorization > - > > Key: OAK-9051 > URL: https://issues.apache.org/jira/browse/OAK-9051 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: authorization-principalbased >Reporter: Ashish Chopra >Assignee: Angela Schreiber >Priority: Major > > Since OAK-8190, a principal based authorization model has been added, which - > among other things - allows creation of Immutable, non-JCR-resource-based > ACEs. [0] > This issue is a request to enhance the existing Oak Exercise module [1] to > illustrate these concepts and how the session with subject containing > different principals operations in a repository (when the principals with > different authorization models are combined). > [0] > https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html > [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-exercise -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9051) Enhance oak-exercise for Principal base authorization
[ https://issues.apache.org/jira/browse/OAK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Angela Schreiber updated OAK-9051: -- Component/s: exercise > Enhance oak-exercise for Principal base authorization > - > > Key: OAK-9051 > URL: https://issues.apache.org/jira/browse/OAK-9051 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: authorization-principalbased, exercise >Reporter: Ashish Chopra >Assignee: Angela Schreiber >Priority: Major > > Since OAK-8190, a principal based authorization model has been added, which - > among other things - allows creation of Immutable, non-JCR-resource-based > ACEs. [0] > This issue is a request to enhance the existing Oak Exercise module [1] to > illustrate these concepts and how the session with subject containing > different principals operations in a repository (when the principals with > different authorization models are combined). > [0] > https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html > [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-exercise -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-9051) Enhance oak-exercise for Principal base authorization
[ https://issues.apache.org/jira/browse/OAK-9051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Chopra updated OAK-9051: --- Component/s: authorization-principalbased > Enhance oak-exercise for Principal base authorization > - > > Key: OAK-9051 > URL: https://issues.apache.org/jira/browse/OAK-9051 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: authorization-principalbased >Reporter: Ashish Chopra >Priority: Major > > Since OAK-8190, a principal based authorization model has been added, which - > among other things - allows creation of Immutable, non-JCR-resource-based > ACEs. [0] > This issue is a request to enhance the existing Oak Exercise module [1] to > illustrate these concepts and how the session with subject containing > different principals operations in a repository (when the principals with > different authorization models are combined). > [0] > https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html > [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-exercise -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-9051) Enhance oak-exercise for Principal base authorization
Ashish Chopra created OAK-9051: -- Summary: Enhance oak-exercise for Principal base authorization Key: OAK-9051 URL: https://issues.apache.org/jira/browse/OAK-9051 Project: Jackrabbit Oak Issue Type: Documentation Reporter: Ashish Chopra Since OAK-8190, a principal based authorization model has been added, which - among other things - allows creation of Immutable, non-JCR-resource-based ACEs. [0] This issue is a request to enhance the existing Oak Exercise module [1] to illustrate these concepts and how the session with subject containing different principals operations in a repository (when the principals with different authorization models are combined). [0] https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html [1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-exercise -- This message was sent by Atlassian Jira (v8.3.4#803005)
