[JBoss JIRA] (ELY-524) Caching support in the LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-524:
---------------------------------
Fix Version/s: 1.1.0.Beta10
(was: 1.1.0.Beta9)
> Caching support in the LDAP realm
> ---------------------------------
>
> Key: ELY-524
> URL: https://issues.jboss.org/browse/ELY-524
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta10
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-624?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-624:
---------------------------------
Fix Version/s: 1.1.0.Beta10
(was: 1.1.0.Beta9)
> Add support for SSO and Clustered SSO
> -------------------------------------
>
> Key: ELY-624
> URL: https://issues.jboss.org/browse/ELY-624
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta10
>
>
> This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO.
> By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1800:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: James Perkins
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> {code}
> /path=invalid(name=name)
> {code}
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1800:
------------------------------------------
Background comment on this for anyone interested in it that I mentioned to James when we were discussing this:
[10:10 AM] Brian Stansberry: a kernel-wide fix just makes me nervous about unintentionally breaking something
[10:11 AM] James R Perkins: Okay. It made me a bit nervous too which is why I didn't submit a PR :)
[10:12 AM] Brian Stansberry: I think a long time ago we said that runtime-only resources still have to expose a Resource in the tree, but I believe that was still after a lot of subsystems were written
Basically a fix for this would likely further enforce the rule that a Resource must be present in the tree, which may break some old stuff. I think it's the right thing to do at some point anyway, but as part of it we need to recognize the potential for breakage and do some analysis of runtime-only resources to ensure they are done correctly.
TBH there may have been some other changes (e.g. in read-resource handling) that would have resulted in breakage if this rule wasn't being followed. But we should be cautious.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: James Perkins
> Assignee: Brian Stansberry
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> {code}
> /path=invalid(name=name)
> {code}
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1291) Rule Compilation errors on mac and windows
by Robert (Bob) Brodt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1291?page=com.atlassian.jira.plugi... ]
Robert (Bob) Brodt closed DROOLS-1291.
--------------------------------------
Release Notes Text: A change in the Eclipse Neon JDT surfaced a bug in the Drools Java compiler interface. This was not an issue with the Eclipse Mars JDT.
Fix Version/s: 6.5.0.CR2
Resolution: Duplicate Issue
This is a duplicate of DROOLS-1250
> Rule Compilation errors on mac and windows
> ------------------------------------------
>
> Key: DROOLS-1291
> URL: https://issues.jboss.org/browse/DROOLS-1291
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 6.4.0.Final
> Environment: RHDS 10.0.0.GA + RHDSIS 10.0.0.Alpha1 (JBoss Drools 6.4.1.Final-v20160503-1355-B205)
> Reporter: Andrej Podhradsky
> Assignee: Robert (Bob) Brodt
> Priority: Blocker
> Fix For: 6.5.0.CR2
>
> Attachments: drools_error.png
>
>
> The following error occurs on mac and windows after creating a drools project in Problems view
> {code}
> Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package
> Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package
> KnowledgeHelper cannot be resolved to a type
> com.sample.DroolsTest.Message cannot be resolved to a type
> org.kie.api.runtime.rule.FactHandle cannot be resolved to a type
> org.kie.api.runtime.rule.FactHandle cannot be resolved to a type
> java.lang.Exception cannot be resolved to a type
> org.kie.api.runtime.rule.RuleContext cannot be resolved to a type
> Message.GOODBYE cannot be resolved to a type
> org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type
> com.sample.DroolsTest.Message cannot be resolved to a type
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1800) Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1800?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1800:
----------------------------------
Description:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid(name=name)
{code}
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
was:
If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
{code}
/path=invalid(name=name)
{code}
For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> Executing a read-attribute operation is allowed on non-existing resources with for attributes with defined read handlers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1800
> URL: https://issues.jboss.org/browse/WFCORE-1800
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: James Perkins
> Assignee: Brian Stansberry
> Attachments: WFCORE-1800.patch
>
>
> If an attribute defines an {{OperationStepHandler}} the global {{read-attribute}} operation will execute the handler regardless if the resource exists.
> Here's an example that will successfully execute and return the name {{invalid}} for the {{name}} attribute even though the resource does not exist.
> {code}
> /path=invalid(name=name)
> {code}
> For attributes that use the default means of reading the attribute value the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
> The attached patch simply invokes the {{context.readResource(PathAddress.EMPTY_ADDRESS, false)}} before the invocation of the custom OSH.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months