[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1115:
----------------------------
Labels: management-model principal-transformer (was: KK-DR18 eap7.1-rfe-failure management-model principal-transformer)
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: ELY-1115
> URL: https://issues.jboss.org/browse/ELY-1115
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta38
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: management-model, principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2740) Recursive read-resource should not fail if an expected address type disappears in the middle of execution
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2740:
----------------------------------------
Summary: Recursive read-resource should not fail if an expected address type disappears in the middle of execution
Key: WFCORE-2740
URL: https://issues.jboss.org/browse/WFCORE-2740
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 4.0.0.Alpha1
The ManagementResourceRegistration tree is not cloned upon modification the way Resource tree is. That means read ops executing concurrently with ops that modify the MRR tree can have the tree change underneath them.
This can affect recursive read-resource ops, as they calculate possible child addresses and then later they process those addresses, failing if an MRR is missing. A failure only makes sense if the user did something wrong or, perhaps, if it's clear that the code is broken. But here there's a perfectly valid reason for the MRR to be missing, so there should be no failure.
Not an urgent thing; I saw this quite a while ago when investigating a different issue and quickly worked up a fix which has now been sitting around gathering dust.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Daniel B. (JIRA)
Daniel B. created DROOLS-1541:
---------------------------------
Summary: newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
Key: DROOLS-1541
URL: https://issues.jboss.org/browse/DROOLS-1541
Project: Drools
Issue Type: Bug
Affects Versions: 6.5.0.Final, 6.3.0.Final
Reporter: Daniel B.
Assignee: Edson Tirelli
The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
The documentation says:
{quote}
11.2.2. InsertObjectCommand
...
outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
{quote}
Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
(It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools
by G Xiong (JIRA)
G Xiong created DROOLS-1540:
-------------------------------
Summary: Drools does not work with spring-boot-devtools
Key: DROOLS-1540
URL: https://issues.jboss.org/browse/DROOLS-1540
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.Final
Reporter: G Xiong
Assignee: Mario Fusco
Priority: Critical
Attachments: complete.zip
Drools does work with spring-boot-devtools.
If you add in pom.xml the following, no rules will be fired in Drools.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
</dependency>
if you comment out this, then rules will be fired in Drools.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2730) empty target-name in constant-permission-mapper is not allowed
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2730?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-2730:
-------------------------------
Description:
For some purposes there is need to construct permission with blank string as param (name/action) - for example *WebResourcePermission*.
Such permission cannot be currently assigned using *constant-permission-mapper* because it requires at least one character to be not-null:
If I try to assing permission with blank name ({{target-name=""}}) (example in steps to reproduce), parse error is thrown:
{code}
| > ParseError at [row,col]:[367,5]
| > Message: "WFLYCTL0113: '' is an invalid value for parameter
| > target-name. Values must have a minimum length of 1 characters"
{code}
was:
I need to have an empty target-name because of the WebResourcePermission. But with unspecified target-name the primary underlying error message was:
{code}
| > ParseError at [row,col]:[367,5]
| > Message: "WFLYCTL0113: '' is an invalid value for parameter
| > target-name. Values must have a minimum length of 1 characters"
{code}
> empty target-name in constant-permission-mapper is not allowed
> --------------------------------------------------------------
>
> Key: WFCORE-2730
> URL: https://issues.jboss.org/browse/WFCORE-2730
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Eva Jarkovská
> Assignee: Jan Kalina
>
> For some purposes there is need to construct permission with blank string as param (name/action) - for example *WebResourcePermission*.
> Such permission cannot be currently assigned using *constant-permission-mapper* because it requires at least one character to be not-null:
> If I try to assing permission with blank name ({{target-name=""}}) (example in steps to reproduce), parse error is thrown:
> {code}
> | > ParseError at [row,col]:[367,5]
> | > Message: "WFLYCTL0113: '' is an invalid value for parameter
> | > target-name. Values must have a minimum length of 1 characters"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8674) Principal from @RunAsPrincipal bean annotation does not get authorised with role from @RunAs bean annotation unless the user exists in backing security realm
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8674?page=com.atlassian.jira.plugin.... ]
Farah Juma moved JBEAP-10636 to WFLY-8674:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8674 (was: JBEAP-10636)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Security
(was: EJB)
(was: Security)
Affects Version/s: (was: 7.1.0.DR12)
(was: 7.1.0.DR13)
(was: 7.1.0.DR14)
(was: 7.1.0.DR16)
(was: 7.1.0.DR15)
(was: 7.1.0.DR17)
> Principal from @RunAsPrincipal bean annotation does not get authorised with role from @RunAs bean annotation unless the user exists in backing security realm
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8674
> URL: https://issues.jboss.org/browse/WFLY-8674
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
> Labels: KK-DR18, eap7.1-rfe-blocker, eap71_beta_candidate
>
> If a bean is annotated with both {{@RunAs}} and {{@RunAsPrincipal}} annotations, the principal will not get authorised unless the user with such principal exists in security realm that the bean is backed by.
> This was not the case with PicketBox. Since the existing EJB-Elytron integration analyses and documentation does not mention such a modification and the change makes an AS TS test case fail, this is an unexpected change of behavior.
> Reproducer and sources attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8673) ASYM_ENCRYPT legacy configuration should not attempt to create elytron reference
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8673?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10635 to WFLY-8673:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8673 (was: JBEAP-10635)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
(was: Migration)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR16)
> ASYM_ENCRYPT legacy configuration should not attempt to create elytron reference
> --------------------------------------------------------------------------------
>
> Key: WFLY-8673
> URL: https://issues.jboss.org/browse/WFLY-8673
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: eap7.1-rfe-failure
>
> I found that currently, when configuring {{ASYM_ENCRYPT}} in legacy way, an elytron key-store reference is always automatically created. That should not happen as people who want to use the legacy security may want to remove the Elytron subsystem entirely. JGroups boot would fail in that case.
> {noformat}
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT:add()
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT/property=encrypt_entire_message:add(value=true)
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT/property=sym_keylength:add(value=512)
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT/property=sym_algorithm:add(value=AES/ECB/PKCS5Padding)
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT/property=asym_keylength:add(value=512)
> /subsystem=jgroups/stack=udp2/protocol=ASYM_ENCRYPT/property=asym_algorithm:add(value=RSA)
> {noformat}
> Here, I removed the elytron subsystem and used configuration from JBEAP-8405.
> {noformat}
> 12:56:22,202 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("stack" => "tcp"),
> ("protocol" => "ASYM_ENCRYPT")
> ]) - failure description: "WFLYCLJG0026: No add operation registered at /subsystem=elytron/key-store=jgroups-tcp"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months