[JBoss JIRA] (WFLY-13838) plain text j_password appears in the legacy audit log
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13838?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13838:
------------------------------------
Fix Version/s: 21.0.0.Beta1
> plain text j_password appears in the legacy audit log
> -----------------------------------------------------
>
> Key: WFLY-13838
> URL: https://issues.redhat.com/browse/WFLY-13838
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 20.0.1.Final
> Reporter: Hisanobu Okuda
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 21.0.0.Beta1
>
> Attachments: web-form-auth.tar.gz
>
>
> The unmasked value of j_password is written in the audit log as `[parameters=guest::,guest::,]`.
> {code}
> 12:48:45,385 TRACE [org.jboss.security.audit] (default task-1) [Success]principal=guest;request=[/test:cookies=[javax.servlet.http.Cookie@46b3f22]:headers=Origin=http://localhost:8080,Cookie=JSESSIONID=dbDjUA6QeA2UXCyyPaqdSSgE4Kjd0_JvxUG7-pBx.localhost,Accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8,User-Agent=Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0,Connection=keep-alive,Referer=http://localhost:8080/test/secure/index.jsp,Host=localhost:8080,Accept-Encoding=gzip, deflate,DNT=1,Upgrade-Insecure-Requests=1,Accept-Language=en-US,en;q=0.5,Content-Length=33,Content-Type=application/x-www-form-urlencoded,][parameters=guest::,guest::,][attributes=];message=UT000030: User guest successfully authenticated.;Source=org.wildfly.extension.undertow.security.AuditNotificationReceiver;
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5517) Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5517?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5517 at 9/11/20 12:48 AM:
---------------------------------------------------------------------
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
- Option C)
** Create DMNContextFPAImpl with OutputSet instance first (the values can be populated from InputSet)
** Before DMNRuntime execution, convert from DMNContextFPAImpl to DMNContextImpl (So the internal execution logic doesn't change)
** After evaluation, client can convert result DMNContextImpl to DMNContextFPAImpl with OutputSet.
was (Author: tkobayashi):
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
> Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
> --------------------------------------------------------------------------
>
> Key: DROOLS-5517
> URL: https://issues.redhat.com/browse/DROOLS-5517
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5502 was to generate OutputSet class and convert DMNResult.getContext().getAll() to the OutputSet externally. This JIRA aims to convert it inside DMNRuntime so that we can get the OutputSet from DMNResult.getContext().getXXX() directly.
> https://github.com/kiegroup/drools/pull/2993#pullrequestreview-451150317
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5517) Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5517?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5517 at 9/11/20 12:48 AM:
---------------------------------------------------------------------
Ideas:
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
- Option C)
** Create DMNContextFPAImpl with OutputSet instance first (the values can be populated from InputSet)
** Before DMNRuntime execution, convert from DMNContextFPAImpl to DMNContextImpl (So the internal execution logic doesn't change)
** After evaluation, client can convert from result DMNContextImpl to DMNContextFPAImpl with OutputSet.
was (Author: tkobayashi):
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
- Option C)
** Create DMNContextFPAImpl with OutputSet instance first (the values can be populated from InputSet)
** Before DMNRuntime execution, convert from DMNContextFPAImpl to DMNContextImpl (So the internal execution logic doesn't change)
** After evaluation, client can convert from result DMNContextImpl to DMNContextFPAImpl with OutputSet.
> Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
> --------------------------------------------------------------------------
>
> Key: DROOLS-5517
> URL: https://issues.redhat.com/browse/DROOLS-5517
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5502 was to generate OutputSet class and convert DMNResult.getContext().getAll() to the OutputSet externally. This JIRA aims to convert it inside DMNRuntime so that we can get the OutputSet from DMNResult.getContext().getXXX() directly.
> https://github.com/kiegroup/drools/pull/2993#pullrequestreview-451150317
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5517) Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5517?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5517 at 9/11/20 12:48 AM:
---------------------------------------------------------------------
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
- Option C)
** Create DMNContextFPAImpl with OutputSet instance first (the values can be populated from InputSet)
** Before DMNRuntime execution, convert from DMNContextFPAImpl to DMNContextImpl (So the internal execution logic doesn't change)
** After evaluation, client can convert from result DMNContextImpl to DMNContextFPAImpl with OutputSet.
was (Author: tkobayashi):
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
- Option C)
** Create DMNContextFPAImpl with OutputSet instance first (the values can be populated from InputSet)
** Before DMNRuntime execution, convert from DMNContextFPAImpl to DMNContextImpl (So the internal execution logic doesn't change)
** After evaluation, client can convert result DMNContextImpl to DMNContextFPAImpl with OutputSet.
> Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
> --------------------------------------------------------------------------
>
> Key: DROOLS-5517
> URL: https://issues.redhat.com/browse/DROOLS-5517
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5502 was to generate OutputSet class and convert DMNResult.getContext().getAll() to the OutputSet externally. This JIRA aims to convert it inside DMNRuntime so that we can get the OutputSet from DMNResult.getContext().getXXX() directly.
> https://github.com/kiegroup/drools/pull/2993#pullrequestreview-451150317
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5517) Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5517?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5517 at 9/11/20 12:44 AM:
---------------------------------------------------------------------
-Ideas:-
- -Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)-
- -Option A)-
-- -Share DMNContextFPAImpl for both InputSet and OutputSet-
-- -DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance-
-- -DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity-
- -Option B)-
-- -Map and Recreate DMNContext right before returning evaluateXXX().-
-[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/impl/DMNRuntimeImpl.java#L116]-
was (Author: tkobayashi):
Ideas:
- Add a method to get OutputSet from DMNContext impl (and want isTypeSafe() method in Interface?)
- Option A)
-- Share DMNContextFPAImpl for both InputSet and OutputSet
-- DMNContextFPAImpl.clone() will return DMNContextFPAImpl instance
-- DMNContextFPAImpl will delegate operations to DMNContextImpl in order to avoid complexity
- Option B)
-- Map and Recreate DMNContext right before returning evaluateXXX().
[https://github.com/kiegroup/drools/blob/7.40.0.Final/kie-dmn/kie-dmn-core...]
> Enhance DMNResult/DMNContext to be able to return strongly typed OutputSet
> --------------------------------------------------------------------------
>
> Key: DROOLS-5517
> URL: https://issues.redhat.com/browse/DROOLS-5517
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Affects Versions: 7.40.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> DROOLS-5502 was to generate OutputSet class and convert DMNResult.getContext().getAll() to the OutputSet externally. This JIRA aims to convert it inside DMNRuntime so that we can get the OutputSet from DMNResult.getContext().getXXX() directly.
> https://github.com/kiegroup/drools/pull/2993#pullrequestreview-451150317
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5631?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi updated DROOLS-5631:
--------------------------------------
Story Points: 8
> Rule evaluation optimization
> ----------------------------
>
> Key: DROOLS-5631
> URL: https://issues.redhat.com/browse/DROOLS-5631
> Project: Drools
> Issue Type: Story
> Components: core engine
> Affects Versions: 7.42.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later.
> Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain.
> Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13839) Undertow https listener does not generate required capability
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13839?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13839 at 9/10/20 9:08 PM:
---------------------------------------------------------------------
Some context.
Undertow provides listeners such as ajp-listener, http-listener and https-listener which listen for incoming connections on ports (using a Listener instance which is registered with a Remoting-based ListenerRegistry). To represent this, all listeners register a dynamic capability org.wildfly.undertow.listener, where the rest of the capability name is filled out with the listener name.
Additionally, the http-listener and https-listeners provide the ability to do HTTP Upgrade (using a named ChannelUpgradeHandler service) and this is represented by them registering a dynamic capability org.wildfly.undertow.listener.http-upgrade-registry, where the rest of the capability name is filled out with the listener name.
The problem here was that the http-listener had an http-upgrade-registry capability registered,but not the https-listener. This was easily added to the HttpsListenerResourceDefinition.
However, once this was done, the Undertow subsystem tests started failing with an unknown boot error. After some considerable debugging, this was traced to the use of a setCapabilityRequirement(String requirement) method on the ssl-context attribute of the HttpsListenerResourceDefinition. Adding in the second capability violated the "single-capability-only" requirement of this method and created an unknown boot error that was very difficult to trace.
was (Author: rachmato):
Some context.
Undertow provides listeners such as ajp-listener, http-listener and https-listener which listen for incoming connections on ports (using a Listener instance which is registered with a Remoting-based ListenerRegistry). To represent this, all listeners register a dynamic capability org.wildfly.undertow.listener, where the rest of the capability name is filled out with the listener name.
Additionally, the http-listener and https-listeners provide the ability to do HTTP Upgrade (using a named ChannelUpgradeHandler service) and this is represented by them registering a dynamic capability org.wildfly.undertow.listener.http-upgrade-registry, where the rest of the capability name is filled out with the listener name.
The problem here was that the http-listener had an http-upgrade-registry capability registered,but not the https-listener. This was easily added to the ResourceDefinition.
Once this was done, the Undertow subsystem tests started failing with an unknown boot error. Some time later, this was traced to the use of a setCapabilityRequirement(String requirement) method on the ssl-context attribute of the HttpsListenerResourceDefinition. Adding in the second capability violated the "single-capability-only" requirement of this method and created an unknown boot error that was very difficult to trace.
> Undertow https listener does not generate required capability
> -------------------------------------------------------------
>
> Key: WFLY-13839
> URL: https://issues.redhat.com/browse/WFLY-13839
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The http-listener of Undertow generates two capabilities: an org.wildfly.undertow.listener capability as well as an org.wildfly.undertow.listener.http-upgrade-registry capabiility.
> This is done for http-listener but not for https-listener.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13839) Undertow https listener does not generate required capability
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13839?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13839:
--------------------------------------------
Some context.
Undertow provides listeners such as ajp-listener, http-listener and https-listener which listen for incoming connections on ports (using a Listener instance which is registered with a Remoting-based ListenerRegistry). To represent this, all listeners register a dynamic capability org.wildfly.undertow.listener, where the rest of the capability name is filled out with the listener name.
Additionally, the http-listener and https-listeners provide the ability to do HTTP Upgrade (using a named ChannelUpgradeHandler service) and this is represented by them registering a dynamic capability org.wildfly.undertow.listener.http-upgrade-registry, where the rest of the capability name is filled out with the listener name.
The problem here was that the http-listener had an http-upgrade-registry capability registered,but not the https-listener. This was easily added to the ResourceDefinition.
Once this was done, the Undertow subsystem tests started failing with an unknown boot error. Some time later, this was traced to the use of a setCapabilityRequirement(String requirement) method on the ssl-context attribute of the HttpsListenerResourceDefinition. Adding in the second capability violated the "single-capability-only" requirement of this method and created an unknown boot error that was very difficult to trace.
> Undertow https listener does not generate required capability
> -------------------------------------------------------------
>
> Key: WFLY-13839
> URL: https://issues.redhat.com/browse/WFLY-13839
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 21.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> The http-listener of Undertow generates two capabilities: an org.wildfly.undertow.listener capability as well as an org.wildfly.undertow.listener.http-upgrade-registry capabiility.
> This is done for http-listener but not for https-listener.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months