May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4730) Include the wildfly-openssl s390 binding

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4730?page=com.atlassian.jira.plug... ] Farah Juma commented on WFCORE-4730: ------------------------------------ [~dlofthouse] The main thing we're missing is a machine on which we can perform this build. I'll ping Yaakov Selkowitz (he added the linux-s390x profile to the wildfly-openssl repo) to see if he could possibly build this for us for the current release. > Include the wildfly-openssl s390 binding > ---------------------------------------- > > Key: WFCORE-4730 > URL: https://issues.redhat.com/browse/WFCORE-4730 > Project: WildFly Core > Issue Type: Enhancement > Components: Build System, Security > Reporter: Brian Stansberry > Assignee: Farah Juma > Priority: Major > > The wildfly-openssl project include s390 bindings; we should include them. > https://github.com/wildfly/wildfly-openssl/tree/1.0.8.Final/linux-s390x > The code was there for the 1.0.8 release but it doesn't look like that variant was built and pushed to nexus: > https://repository.jboss.org/org/wildfly/openssl/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13269) The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13269?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFLY-13269. ------------------------------------- Resolution: Done > The org.wildfly:wildfly-client-all artefact incorrectly contains the Elytron CDI extension > ------------------------------------------------------------------------------------------ > > Key: WFLY-13269 > URL: https://issues.redhat.com/browse/WFLY-13269 > Project: WildFly > Issue Type: Bug > Components: Build System, MP JWT, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 20.0.0.Beta1 > > > This means if the artefact is included in a deployment the JWT activation is incorrectly triggered but with some dependencies missing leading to an error such as the following. > {code} > 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension > at java.lang.ClassLoader.defineClass1(ClassLoader.java) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1948) wildfly-elytron HTTP JWT Bearer realm CORS

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1948?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned ELY-1948: ------------------------------------- Assignee: (was: Darran Lofthouse) > wildfly-elytron HTTP JWT Bearer realm CORS > ------------------------------------------ > > Key: ELY-1948 > URL: https://issues.redhat.com/browse/ELY-1948 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Jan Bárta > Priority: Optional > > Hi, > i found possible problem with HTTP Bearer JWT. > If you need create dynamically CORS by +own policy JAXRS filter+, then it will be problem with expired/invalid (any other problem) JWT token. You will see CORS exception on expired/invalid JWT because wildfly-elytron refuse request before own policy JAXRS filters (as e.g. @PreMatching ContainerRequestFilter, ContainerResponseFilter). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1934) SSO support for BASIC authentication

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1934?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned ELY-1934: ------------------------------------- Assignee: (was: Darran Lofthouse) > SSO support for BASIC authentication > ------------------------------------ > > Key: ELY-1934 > URL: https://issues.redhat.com/browse/ELY-1934 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Mark Banierink > Priority: Major > > With the legacy login system, single sign-on was supported for any mechanism. However, when using Elytron, SSO is supported for FORM, SPNEGO and CLIENT-CERT, but not supported for BASIC authentication mechanism. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-168) JMX proxy connection is released sooner than the client asks for closing it

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/REMJMX-168?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on REMJMX-168: ----------------------------------------- [~ochaloup] Could you please check if this still happens, there was another bug reported in relation to REMJMX-160 which has now been fixed https://issues.redhat.com/browse/REMJMX-166 > JMX proxy connection is released sooner than the client asks for closing it > --------------------------------------------------------------------------- > > Key: REMJMX-168 > URL: https://issues.redhat.com/browse/REMJMX-168 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 3.0.2.Final, 3.0.3.Final > Reporter: Ondrej Chaloupka > Priority: Major > > We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160. > What we hit: > It seems the JMX connection *is closed* too soon - before the client decides to release it. > The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails. > Our test does: > * The transaction recovery test creates the JMX proxy at some point to verify content of object store. > * Then there is some idle time where the JMX proxy is not utilized. > * When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails. > From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....). > When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-168) JMX proxy connection is released sooner than the client asks for closing it

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/REMJMX-168?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned REMJMX-168: --------------------------------------- Assignee: (was: Darran Lofthouse) > JMX proxy connection is released sooner than the client asks for closing it > --------------------------------------------------------------------------- > > Key: REMJMX-168 > URL: https://issues.redhat.com/browse/REMJMX-168 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 3.0.2.Final, 3.0.3.Final > Reporter: Ondrej Chaloupka > Priority: Major > > We started to hit the issue on Narayana transaction recovery testing. Reported as JBEAP-18109. It seems to be caused by changes made at REMJMX-160. > What we hit: > It seems the JMX connection *is closed* too soon - before the client decides to release it. > The client creates a JMX proxy. Then it does not use it for a while. And then it runs the JMX calls again. Such attempt then fails. > Our test does: > * The transaction recovery test creates the JMX proxy at some point to verify content of object store. > * Then there is some idle time where the JMX proxy is not utilized. > * When the testsuite tries to verify the content of object store once again on the same JMX proxy that attempt fails. > From investigation it seems that it could be caused by the fact that {{Executors.newCachedThreadPool}} (https://github.com/jbossas/remoting-jmx/blob/3.0.3.Final/src/main/java/or...) is used for thread creation. The JMX thread is idle more than 60 seconds and the thread pool may dispose the threads after that time (after 60s, see https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors....). > When I used the {{Executors.newFixedThreadPool}} (https://github.com/ochaloup/remoting-jmx/commit/7ec37c8a09f4d8229ee8263ad...) the issue disappeared. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4730) Include the wildfly-openssl s390 binding

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4730?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-4730: ------------------------------------------ [~fjuma] This probably should be in the WFSSL project instead of here but is this something that can be considered in the current release? > Include the wildfly-openssl s390 binding > ---------------------------------------- > > Key: WFCORE-4730 > URL: https://issues.redhat.com/browse/WFCORE-4730 > Project: WildFly Core > Issue Type: Enhancement > Components: Build System, Security > Reporter: Brian Stansberry > Assignee: Farah Juma > Priority: Major > > The wildfly-openssl project include s390 bindings; we should include them. > https://github.com/wildfly/wildfly-openssl/tree/1.0.8.Final/linux-s390x > The code was there for the 1.0.8 release but it doesn't look like that variant was built and pushed to nexus: > https://repository.jboss.org/org/wildfly/openssl/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4730) Include the wildfly-openssl s390 binding

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4730?page=com.atlassian.jira.plug... ] Darran Lofthouse reassigned WFCORE-4730: ---------------------------------------- Assignee: Farah Juma (was: Darran Lofthouse) > Include the wildfly-openssl s390 binding > ---------------------------------------- > > Key: WFCORE-4730 > URL: https://issues.redhat.com/browse/WFCORE-4730 > Project: WildFly Core > Issue Type: Enhancement > Components: Build System, Security > Reporter: Brian Stansberry > Assignee: Farah Juma > Priority: Major > > The wildfly-openssl project include s390 bindings; we should include them. > https://github.com/wildfly/wildfly-openssl/tree/1.0.8.Final/linux-s390x > The code was there for the 1.0.8 release but it doesn't look like that variant was built and pushed to nexus: > https://repository.jboss.org/org/wildfly/openssl/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11492) Quickstart http-custom-mechanism: documentation step fails

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-11492?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-11492: --------------------------------------- Assignee: (was: Darran Lofthouse) > Quickstart http-custom-mechanism: documentation step fails > ---------------------------------------------------------- > > Key: WFLY-11492 > URL: https://issues.redhat.com/browse/WFLY-11492 > Project: WildFly > Issue Type: Bug > Components: Documentation, Security > Reporter: Alan Hantke > Priority: Major > > Step #3, entitled *Configure the Application Security Domain* has the developer executing the following CLI command: > {code:java} > $ {jbossHomeName}/bin/jboss-cli.sh --connect --file=configure-security-domain.cli > {code} > However, this results in the following error: > {code:java} > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): > WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: > Step: step-1 > Operation: /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication) > Failure: WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.http-authentication-factory.application-http-authentication; Possible registration points for this capability: > /subsystem=elytron/http-authentication-factory=* > {code} > I am by no means an expert on this, but in looking at the standalone.xml file, I think that there needs to be a mate for the inserted *application-http-authentication*. I have attempted to continue without this changes installed by the CLI, but I am unable to execute the webapp even after providing the correct user/pass in the BASIC AUTH. > I have verified that the same problem-causing syntax exists on the quickstart 'master', although I have been using branch '14.x' because neither 15.x nor 'master' would build when I execute 'mvn clean build'. Finally, the I encounter the problem with fresh installs of WildFly versions 10.1.0 and 14.0. > Please change change the project if I have categorized the ticket incorrectly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11492) Quickstart http-custom-mechanism: documentation step fails

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-11492?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-11492: ------------------------------------ Component/s: Security > Quickstart http-custom-mechanism: documentation step fails > ---------------------------------------------------------- > > Key: WFLY-11492 > URL: https://issues.redhat.com/browse/WFLY-11492 > Project: WildFly > Issue Type: Bug > Components: Documentation, Security > Reporter: Alan Hantke > Assignee: Darran Lofthouse > Priority: Major > > Step #3, entitled *Configure the Application Security Domain* has the developer executing the following CLI command: > {code:java} > $ {jbossHomeName}/bin/jboss-cli.sh --connect --file=configure-security-domain.cli > {code} > However, this results in the following error: > {code:java} > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): > WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: > Step: step-1 > Operation: /subsystem=undertow/application-security-domain=other:add(http-authentication-factory=application-http-authentication) > Failure: WFLYCTL0369: Required capabilities are not available: > org.wildfly.security.http-authentication-factory.application-http-authentication; Possible registration points for this capability: > /subsystem=elytron/http-authentication-factory=* > {code} > I am by no means an expert on this, but in looking at the standalone.xml file, I think that there needs to be a mate for the inserted *application-http-authentication*. I have attempted to continue without this changes installed by the CLI, but I am unable to execute the webapp even after providing the correct user/pass in the BASIC AUTH. > I have verified that the same problem-causing syntax exists on the quickstart 'master', although I have been using branch '14.x' because neither 15.x nor 'master' would build when I execute 'mvn clean build'. Finally, the I encounter the problem with fresh installs of WildFly versions 10.1.0 and 14.0. > Please change change the project if I have categorized the ticket incorrectly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 2020