May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10484) Upgrade Picketlink from 2.5.5.SP11 to 2.5.5.SP12

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-10484?page=com.atlassian.jira.plugin... ] Tomas Hofman updated WFLY-10484: -------------------------------- Description: (was: https://github.com/jbossas/redhat-picketlink-bindings/compare/v2.5.5.SP10... and https://github.com/jbossas/redhat-picketlink/compare/v2.5.5.SP10...eap-7.x) > Upgrade Picketlink from 2.5.5.SP11 to 2.5.5.SP12 > ------------------------------------------------ > > Key: WFLY-10484 > URL: https://issues.jboss.org/browse/WFLY-10484 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Tomas Hofman > Assignee: Lin Gao > Labels: downstream_dependency > Fix For: 13.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10484) Upgrade Picketlink from 2.5.5.SP11 to 2.5.5.SP12

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-10484: ----------------------------------- Summary: Upgrade Picketlink from 2.5.5.SP11 to 2.5.5.SP12 Key: WFLY-10484 URL: https://issues.jboss.org/browse/WFLY-10484 Project: WildFly Issue Type: Component Upgrade Components: Build System Reporter: Tomas Hofman Assignee: Lin Gao Fix For: 13.0.0.Beta1 https://github.com/jbossas/redhat-picketlink-bindings/compare/v2.5.5.SP10... and https://github.com/jbossas/redhat-picketlink/compare/v2.5.5.SP10...eap-7.x -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10483) We are using wildfly 10.1.0. Final for our project. We want to know that Default Max Concurrent User limit & Max thread limit. Please guide us. How we can customize above shared parameter.

by Ravi Rai (JIRA)

Ravi Rai created WFLY-10483: ------------------------------- Summary: We are using wildfly 10.1.0. Final for our project. We want to know that Default Max Concurrent User limit & Max thread limit. Please guide us. How we can customize above shared parameter. Key: WFLY-10483 URL: https://issues.jboss.org/browse/WFLY-10483 Project: WildFly Issue Type: Feature Request Reporter: Ravi Rai Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10482) Wildfly 12.0.0.Final sets response header server:Wildfly/11

by Puzzle ITC (JIRA)

Puzzle ITC created WFLY-10482: --------------------------------- Summary: Wildfly 12.0.0.Final sets response header server:Wildfly/11 Key: WFLY-10482 URL: https://issues.jboss.org/browse/WFLY-10482 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 12.0.0.Final Environment: all Reporter: Puzzle ITC Assignee: Jason Greene Priority: Minor Wildfly 12.0.0.Final sets response header server:Wildfly/11 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS

by Eduardo Martins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ] Eduardo Martins commented on WFLY-9892: --------------------------------------- [~sgilda] even better! > Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS > -------------------------------------------------------------------------------- > > Key: WFLY-9892 > URL: https://issues.jboss.org/browse/WFLY-9892 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 12.0.0.Beta1 > Reporter: Ondrej Lukas > Assignee: Pedro Igor > Priority: Blocker > Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties > > > When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly. > We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly. > Remoting fails due to following exception: > {code} > java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA" > at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117) > at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295) > at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196) > at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95) > at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55) > at java.security.AccessController.doPrivileged(Native Method) > at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374) > at java.lang.Thread.run(Thread.java:748) > {code} > It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like: > {code} > <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue> > {code} > In WildFly 12 it looks like (there are end of lines): > {code} > <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl > qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI > 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N > K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7 > nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue> > {code} > [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10479) mod_cluster "proxies" attribute is missing capability reference

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10479?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10479: ---------------------------------- Description: The capability reference is missing to validate outbound-socket-binding(s). Note for tester, this makes tab completion in CLI missing or makes operations like {{/subsystem=modcluster/proxy=default:write-attribute(name=proxies,value=[x])}} accept any value and then fail on boot. was:This makes operations like {{/subsystem=modcluster/proxy=default:write-attribute(name=proxies,value=[x])}} accept any value and then fail on boot. > mod_cluster "proxies" attribute is missing capability reference > --------------------------------------------------------------- > > Key: WFLY-10479 > URL: https://issues.jboss.org/browse/WFLY-10479 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 13.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > The capability reference is missing to validate outbound-socket-binding(s). > Note for tester, this makes tab completion in CLI missing or makes operations like {{/subsystem=modcluster/proxy=default:write-attribute(name=proxies,value=[x])}} accept any value and then fail on boot. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10479) mod_cluster "proxies" attribute is missing capability reference

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10479?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10479: ---------------------------------- Priority: Critical (was: Major) > mod_cluster "proxies" attribute is missing capability reference > --------------------------------------------------------------- > > Key: WFLY-10479 > URL: https://issues.jboss.org/browse/WFLY-10479 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 13.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > This makes operations like {{/subsystem=modcluster/proxy=default:write-attribute(name=proxies,value=[x])}} accept any value and then fail on boot. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10446) Register undertow deployment services under the deployment service name

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-10446?page=com.atlassian.jira.plugin... ] Peter Palaga commented on WFLY-10446: ------------------------------------- Citing [~swd847] https://github.com/wildfly/wildfly/pull/11274#issuecomment-392419012 {quote} I don't really see any reason for the deployment service name to be this complex. I think it should just be changed to be prefixed on deploymentUnit.getServiceName() like almost every other deployment based service. If we allow this PR in then we are kind of stuck with doing it the way we currently are, as it becomes a bit of an API, so I would prefer that the current code is modified to register the deployment info service under a more appropriate service name. {quote} There is a new PR by Stuart: https://github.com/wildfly/wildfly/pull/11298 > Register undertow deployment services under the deployment service name > ----------------------------------------------------------------------- > > Key: WFLY-10446 > URL: https://issues.jboss.org/browse/WFLY-10446 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Peter Palaga > Assignee: Peter Palaga > > To be able to secure Camel CXF endpoints in WildFly Camel, we need an access to DeploymentInfo produced by UndertowDeploymentInfoService. Currently, the service name of UndertowDeploymentInfoService is assembled out of several parts including server name, host name and deployment name. These three are defined by a complex logic that checks various sources and defaults. So, rather than copying that logic to WildFly Camel, we'd like to pack those names into a data object and attach it to the deploymentUnit so that it is available to our DeploymentProcessor. > A PR follows. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10446) Register undertow deployment services under the deployment service name

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-10446?page=com.atlassian.jira.plugin... ] Peter Palaga updated WFLY-10446: -------------------------------- Summary: Register undertow deployment services under the deployment service name (was: Attach names associated with a deployment to DeploymentUnit) > Register undertow deployment services under the deployment service name > ----------------------------------------------------------------------- > > Key: WFLY-10446 > URL: https://issues.jboss.org/browse/WFLY-10446 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Peter Palaga > Assignee: Peter Palaga > > To be able to secure Camel CXF endpoints in WildFly Camel, we need an access to DeploymentInfo produced by UndertowDeploymentInfoService. Currently, the service name of UndertowDeploymentInfoService is assembled out of several parts including server name, host name and deployment name. These three are defined by a complex logic that checks various sources and defaults. So, rather than copying that logic to WildFly Camel, we'd like to pack those names into a data object and attach it to the deploymentUnit so that it is available to our DeploymentProcessor. > A PR follows. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-270) Document usage of jenkins docker slaves

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-270?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-270. --------------------------------- Resolution: Done Updated https://mojo.redhat.com/docs/DOC-1168333 > Document usage of jenkins docker slaves > --------------------------------------- > > Key: SWSQE-270 > URL: https://issues.jboss.org/browse/SWSQE-270 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > > It would be nice to have documentation describing available slaves, labes, usage of sudo etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 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 2018