May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1454564, https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623, https://bugzilla.redhat.com/show_bug.cgi?id=1149621 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623, https://bugzilla.redhat.com/show_bug.cgi?id=1149621) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1576) Intermittently Rule getting executed Twice while using Agenda Groups and Order

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1576?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1576: ----------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Intermittently Rule getting executed Twice while using Agenda Groups and Order > ------------------------------------------------------------------------------ > > Key: DROOLS-1576 > URL: https://issues.jboss.org/browse/DROOLS-1576 > Project: Drools > Issue Type: Bug > Reporter: Siyad Theyparambil Mohammed > Assignee: Mario Fusco > Attachments: CreateDedCharges-Rule.txt, CreateFLATFeeCharges-Rule.txt, CreatePSRLCreditCharges-Rule.txt, CreateRPERFeeCharges-Rule.txt, First Execution Result.txt, Second Execution Result.txt > > > Hi, > We have 4 rules which are divided into 2 agenda groups > ||Rule||Agenda Group|| > |CreateRPERFeeCharges|createcharges| > |CreateFLATFeeCharges|createcharges| > |CreateDedCharges|createcharges| > |CreatePSRLCreditCharges|postrule| > > Focus is set on the agenda group in the following order, > 1. postrule > 2. createcharges > The Rule “CreatePSRLCreditCharges” has named consequences. Based on the accumulated Charge amount we want one of the two consequence to be executed. If you notice the “First Execution Result.txt” this rule was executed twice once for the “IF” and second for “ELSE” but during the second trigger of the rule execution it fired the rule only once with the same data. Could you please look/check and let us know if we have an issue with the rule or is this a bug in drools? > > We have attached the all the 4 drls and the results of the 2 execution that was triggered. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1193) Elytron token-realm doesn't support unsigned tokens

by Josef Cacek (JIRA)

Josef Cacek created ELY-1193: -------------------------------- Summary: Elytron token-realm doesn't support unsigned tokens Key: ELY-1193 URL: https://issues.jboss.org/browse/ELY-1193 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Verification of JWT tokens with empty signature part fails in Elytron. The Elytron token-realm can be configured to not verify JWT token signature. {code} /subsystem=elytron/token-realm=JwtRealm:add(jwt={}) {code} The JWT specification describes tokens without signature in [RFC 7519 Section 6|https://tools.ietf.org/html/rfc7519#section-6]. When user is comming with such a token the validation in Elytron fails. Sample token: {code} eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJpc3MiOiJpc3N1ZXIud2lsZGZseS5vcmciLCJzdWIiOiJlbHl0cm9uQHdpbGRmbHkub3JnIiwiZXhwIjoyMDUxMjIyMzk5LCJhdWQiOiJlbHl0cm9uLXRlc3QifQ. Header: { "alg": "none", "typ": "JWT" } Payload: { "iss": "issuer.wildfly.org", "sub": "elytron(a)wildfly.org", "exp": 2051222399, "aud": "elytron-test" } {code} The problem is probably in this piece of code in {{JwtValidator}} class: {code:java} String[] parts = jwt.split("\\."); if (parts.length < 3) { throw log.tokenRealmJwtInvalidFormat(); } {code} Even if the token correctly contains 2 dots, the {{split}} returns array of lenght 2 (because the last part is empty). Additional negative-integer argument to the {{split()}} method could help here: {code:java} jwt.split("\\.", -1); {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1187) Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1187?page=com.atlassian.jira.plugin.s... ] Chao Wang resolved ELY-1187. ---------------------------- Resolution: Duplicate Issue > Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1187 > URL: https://issues.jboss.org/browse/ELY-1187 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Chao Wang > Priority: Critical > > When Elytron client configuration file includes sasl-mechanism-selector with string which contains 'or, 'and', 'eq' and 'if' predicate then its values are not parsed correctly. It seems that name of mechanism is parsed as 'name of mechanism'+'1 another character'. > For example, following element for selector in Elytron client configuration file: > {code} > ... > <sasl-mechanism-selector selector="(DIGEST-MD5||JBOSS-LOCAL-USER)"/> > ... > {code} > is parsed as mechanisms {{DIGEST-MD5|}}, {{JBOSS-LOCAL-USER)}}. > The same behavior happens also if predicate {{&&}}, {{==}}, {{x ? y : z}} is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1187) Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1187?page=com.atlassian.jira.plugin.s... ] Chao Wang commented on ELY-1187: -------------------------------- Please see my comments on JBEAP-11077 > Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1187 > URL: https://issues.jboss.org/browse/ELY-1187 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Chao Wang > Priority: Critical > > When Elytron client configuration file includes sasl-mechanism-selector with string which contains 'or, 'and', 'eq' and 'if' predicate then its values are not parsed correctly. It seems that name of mechanism is parsed as 'name of mechanism'+'1 another character'. > For example, following element for selector in Elytron client configuration file: > {code} > ... > <sasl-mechanism-selector selector="(DIGEST-MD5||JBOSS-LOCAL-USER)"/> > ... > {code} > is parsed as mechanisms {{DIGEST-MD5|}}, {{JBOSS-LOCAL-USER)}}. > The same behavior happens also if predicate {{&&}}, {{==}}, {{x ? y : z}} is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1187) Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/ELY-1187?page=com.atlassian.jira.plugin.s... ] Chao Wang reassigned ELY-1187: ------------------------------ Assignee: Chao Wang (was: Darran Lofthouse) > Mechanism names in 'or, 'and', 'eq' or 'if' predicates are not parsed correctly in mechanism selector in Elytron client > ----------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1187 > URL: https://issues.jboss.org/browse/ELY-1187 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Chao Wang > Priority: Critical > > When Elytron client configuration file includes sasl-mechanism-selector with string which contains 'or, 'and', 'eq' and 'if' predicate then its values are not parsed correctly. It seems that name of mechanism is parsed as 'name of mechanism'+'1 another character'. > For example, following element for selector in Elytron client configuration file: > {code} > ... > <sasl-mechanism-selector selector="(DIGEST-MD5||JBOSS-LOCAL-USER)"/> > ... > {code} > is parsed as mechanisms {{DIGEST-MD5|}}, {{JBOSS-LOCAL-USER)}}. > The same behavior happens also if predicate {{&&}}, {{==}}, {{x ? y : z}} is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1192?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1192: ------------------------------ Affects Version/s: 1.1.0.Beta42 > HTTP status 500 when no principal is returned by aggregate-principal-transformer > -------------------------------------------------------------------------------- > > Key: ELY-1192 > URL: https://issues.jboss.org/browse/ELY-1192 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. > This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). > [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1192: --------------------------------- Summary: HTTP status 500 when no principal is returned by aggregate-principal-transformer Key: ELY-1192 URL: https://issues.jboss.org/browse/ELY-1192 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8821) Operation removing http-connector requires full server reload but does not change the server state accordingly

by Michal Jurc (JIRA)

[ https://issues.jboss.org/browse/WFLY-8821?page=com.atlassian.jira.plugin.... ] Michal Jurc edited comment on WFLY-8821 at 5/24/17 1:20 AM: ------------------------------------------------------------ [~brian.stansberry]: I have noticed this when I was implementing a test in AS TS. Without [this|https://github.com/wildfly/wildfly/pull/10040/files#diff-b045ec131e9...] reload at following address, the tests invoking EJBs from client in Integration Basic module of testsuite would attempt to connect to server the old way, receiving HTTP response code 200 indicating the http upgrade response, which happens with active Elytron connector. The only test adding {{http-connector}} backed by Elytron is {{MixedSecurityAnnotationAuthorizationTestCase}}. If that reload is not present, the {{standalone-full.xml}} is clean after the test, server state is {{running}} (not {{reload-required}}), but yet the tests after it that invoke EJBs remotely are clearly connecting to Elytron connector. The tests are ran with this command: {code}mvn clean test -Dtest=org.jboss.as.test.integration.ejb.security.**.*{code} > Operation removing http-connector requires full server reload but does not change the server state accordingly > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8821 > URL: https://issues.jboss.org/browse/WFLY-8821 > Project: WildFly > Issue Type: Bug > Components: Remoting > Reporter: Michal Jurc > Assignee: David Lloyd > > Removing a {{http-connector}} with {{allow-resource-service-restart}} set to {{true}} will yield the following result: > {code}{ > "operation" => "remove", > "address" => [ > ("subsystem" => "remoting"), > ("http-connector" => "ejb3-tests") > ], > "operation-headers" => {"allow-resource-service-restart" => true} > } > {"outcome" => "success"}{code} > However, the removal of {{http-connector}} will only register after full server reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1191) Undertow CLIENT_CERT via Elytron and HTTP/2 does not work

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/ELY-1191?page=com.atlassian.jira.plugin.s... ] Stuart Douglas moved JBEAP-11106 to ELY-1191: --------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1191 (was: JBEAP-11106) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR18) > Undertow CLIENT_CERT via Elytron and HTTP/2 does not work > --------------------------------------------------------- > > Key: ELY-1191 > URL: https://issues.jboss.org/browse/ELY-1191 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content. > I can see following TRACE messages in server.log: > {code} > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client]) > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client] > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser] > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client. > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => [] > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client] > 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https' > 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session > {code} > Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}. > When I disable 'http2' in https-listener: > {code} > /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false) > reload > {code} > I can now access secured content as expected. Also trace log contains different (more healthy) messages now. > This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library. > As described in JBEAP-9803, Undertow needs to write into ssl-context when HTTP/2 with ALPN is utilized. Maybe this might be the source of this problem? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017