January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1836) manual module SSLEJBRemoteClientTestCase keeps freezing

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-1836?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-1836: ------------------------------------ This is closed, but SSLEJBRemoteClientTestCase is still disabled by reference to this issue. SSLEJBRemoteClientTestCase should be enabled again. > manual module SSLEJBRemoteClientTestCase keeps freezing > ------------------------------------------------------- > > Key: WFLY-1836 > URL: https://issues.jboss.org/browse/WFLY-1836 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Bartosz Baranowski > Assignee: Tomaz Cerar > > CI job keeps freezing on this test. In local run, it does not fail however: > execution in batch: 102s+ > standalone : ~45s -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2216) CLI fails to reload when connection upgrades from http to https

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugi... ] Jean-Francois Denise edited comment on WFCORE-2216 at 1/24/17 4:25 AM: ----------------------------------------------------------------------- [~brian.stansberry], so it seems that the RedirectException needs to be analysed prior to take the decision to reconnect or not. I am working on a new fix. was (Author: jdenise): @Brian, so it seems that the RedirectException needs to be analysed prior to take the decision to reconnect or not. I am working on a new fix. > CLI fails to reload when connection upgrades from http to https > --------------------------------------------------------------- > > Key: WFCORE-2216 > URL: https://issues.jboss.org/browse/WFCORE-2216 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha23 > > > reload command should manage to reconnect to a server reconfigured with https management interface. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2216) CLI fails to reload when connection upgrades from http to https

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-2216: ---------------------------------------------- @Brian, so it seems that the RedirectException needs to be analysed prior to take the decision to reconnect or not. I am working on a new fix. > CLI fails to reload when connection upgrades from http to https > --------------------------------------------------------------- > > Key: WFCORE-2216 > URL: https://issues.jboss.org/browse/WFCORE-2216 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha23 > > > reload command should manage to reconnect to a server reconfigured with https management interface. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7905) Wildfly is missing jboss logging internationalization message in XTS

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7905?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated WFLY-7905: --------------------------------- Labels: downstream_dependency (was: ) > Wildfly is missing jboss logging internationalization message in XTS > -------------------------------------------------------------------- > > Key: WFLY-7905 > URL: https://issues.jboss.org/browse/WFLY-7905 > Project: WildFly > Issue Type: Enhancement > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Priority: Minor > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > > There is one log warning message which is not properly internationalized in Wildfly 'xts' submodule: > ./src/xts/src/main/java/org/jboss/as/xts/GracefulShutdownRejectionRule.java:45: XTSLogger.logger.warnf("rejecting call because it is not part of any XTS transaction") > All logs of level WARN and higher should be internationalized. > The message needs to be added to XTS in JBossTS and then xts module modified to use it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1335) Authentication via remoting fail for larger requests i.e. long password

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/JBREM-1335?page=com.atlassian.jira.plugin... ] Wolf-Dieter Fink reassigned JBREM-1335: --------------------------------------- Assignee: David Lloyd > Authentication via remoting fail for larger requests i.e. long password > ----------------------------------------------------------------------- > > Key: JBREM-1335 > URL: https://issues.jboss.org/browse/JBREM-1335 > Project: JBoss Remoting > Issue Type: Bug > Components: general, security > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > If the client use authentication and the passwords is really long, the SASL request or kerberos ticket is huge the attempt will fail. > In the same environment authentication for other users work correct. > The shown message within the server log is > TRACE [org.jboss.remoting.remote.connection handleEvent] (Remoting "gravity" read-1) Connection error detail: java.io.IOException: Received an invalid message length of 11857 > at org.xnio.channels.FramedMessageChannel.receive(FramedMessageChannel.java:106) [xnio-api-3.0.15.GA.jar:3.0.15.GA] > at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:229) [jboss-remoting-3.3.6.Final.jar:3.3.6.Final] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1335) Authentication via remoting fail for larger requests i.e. long password

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created JBREM-1335: --------------------------------------- Summary: Authentication via remoting fail for larger requests i.e. long password Key: JBREM-1335 URL: https://issues.jboss.org/browse/JBREM-1335 Project: JBoss Remoting Issue Type: Bug Components: general, security Reporter: Wolf-Dieter Fink If the client use authentication and the passwords is really long, the SASL request or kerberos ticket is huge the attempt will fail. In the same environment authentication for other users work correct. The shown message within the server log is TRACE [org.jboss.remoting.remote.connection handleEvent] (Remoting "gravity" read-1) Connection error detail: java.io.IOException: Received an invalid message length of 11857 at org.xnio.channels.FramedMessageChannel.receive(FramedMessageChannel.java:106) [xnio-api-3.0.15.GA.jar:3.0.15.GA] at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:229) [jboss-remoting-3.3.6.Final.jar:3.3.6.Final] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7948) Crefential Store intergration into RA subsystem

by Peter Skopek (JIRA)

Peter Skopek created WFLY-7948: ---------------------------------- Summary: Crefential Store intergration into RA subsystem Key: WFLY-7948 URL: https://issues.jboss.org/browse/WFLY-7948 Project: WildFly Issue Type: Sub-task Reporter: Peter Skopek Assignee: Peter Skopek -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7947) The elytron-domain attribute in messaging subsystem doesn't reference capability

by Josef Cacek (JIRA)

Josef Cacek created WFLY-7947: --------------------------------- Summary: The elytron-domain attribute in messaging subsystem doesn't reference capability Key: WFLY-7947 URL: https://issues.jboss.org/browse/WFLY-7947 Project: WildFly Issue Type: Bug Components: JMS, Security Reporter: Josef Cacek Assignee: Jeff Mesnil The {{elytron-domain}} attribute in ActiveMQ server configuration must reference capability "org.wildfly.security.security-domain" to allow value validation and enable auto-completion support in CLI. It's just a STRING value now without validation. Currently it's possible to do following: {code} [standalone@embedded /] /subsystem=messaging-activemq/server=default:write-attribute(name=elytron-domain, value=NoSuchDomain) {"outcome" => "success"} {code} The behavior should be aligned to Batch subsystem for instance: {code} [standalone@embedded /] /subsystem=batch-jberet:write-attribute(name=security-domain,value=NoSuchDomain) { "outcome" => "failed", "failure-description" => "WFLYCTL0369: Required capabilities are not available: org.wildfly.security.security-domain.NoSuchDomain; There are no known registration points which can provide this capability.", "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7946) Elytron ldap-realm does not handle loops in referrals

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7946?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7946: ------------------------------- Description: According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.". When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server. [1] http://tools.ietf.org/html/rfc4511#section-4.1.10 was: According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.". When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server. This issue has been already reported for legacy security during EAP 7.0.0 testing in JBEAP-2156. [1] http://tools.ietf.org/html/rfc4511#section-4.1.10 > Elytron ldap-realm does not handle loops in referrals > ----------------------------------------------------- > > Key: WFLY-7946 > URL: https://issues.jboss.org/browse/WFLY-7946 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.". > When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server. > [1] http://tools.ietf.org/html/rfc4511#section-4.1.10 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7946) Elytron ldap-realm does not handle loops in referrals

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7946?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7946: ------------------------------- Attachment: print-roles.war > Elytron ldap-realm does not handle loops in referrals > ----------------------------------------------------- > > Key: WFLY-7946 > URL: https://issues.jboss.org/browse/WFLY-7946 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: print-roles.war > > > According to LDAP specification [1]: "Clients that follow referrals MUST ensure that they do not loop between servers. They MUST NOT repeatedly contact the same server for the same request with the same parameters.". > When application server is configured to use ldap-realm with dir-context which uses referral-mode=follow or throw and LDAP servers contain loop then it leads to infinite cycle. It can results to java.lang.OutOfMemoryError on EAP server. > [1] http://tools.ietf.org/html/rfc4511#section-4.1.10 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 January 2017