September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1701) In-VM Identity Representation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1701: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > In-VM Identity Representation > ----------------------------- > > Key: WFCORE-1701 > URL: https://issues.jboss.org/browse/WFCORE-1701 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > If Elytron has no current SecurityIdentity then an anonymous identity is used. The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established. > We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client Config 1.0.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1694: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to WildFly Client Config 1.0.0.Beta1 > -------------------------------------------- > > Key: WFCORE-1694 > URL: https://issues.jboss.org/browse/WFCORE-1694 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting 5.0.0.Beta4

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1693: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to JBoss Remoting 5.0.0.Beta4 > ------------------------------------- > > Key: WFCORE-1693 > URL: https://issues.jboss.org/browse/WFCORE-1693 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX 3.0.0.Alpha1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1691: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to Remoting JMX 3.0.0.Alpha1 > ------------------------------------ > > Key: WFCORE-1691 > URL: https://issues.jboss.org/browse/WFCORE-1691 > Project: WildFly Core > Issue Type: Component Upgrade > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1805) Intermittent failure in BasicOperationsUnitTestCase.testPathInfo

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1805?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1805: ------------------------------------------ The PR is merged for Alpha9 but I'll leave this open until https://github.com/wildfly/wildfly-core/pull/1837 is in as well as that further hardens the test. > Intermittent failure in BasicOperationsUnitTestCase.testPathInfo > ---------------------------------------------------------------- > > Key: WFCORE-1805 > URL: https://issues.jboss.org/browse/WFCORE-1805 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha9 > > > This test is failing intermittently. I'm going to @Ignore it. > This one should be a bit higher priority than the typical intermittent test failure as the stuff being tested is pretty new, so there's a higher chance this is a bug in the code instead of just a test issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6784: -------------------------------------- The PR was actually correct. Unfortunately the PR fixed a bug (websockets would always be enabled even if there is no websocket element) and that uncovered a problem with the TCK config (namely that websockets are not enabled). > Add possibility to enable websocket compression via management model > -------------------------------------------------------------------- > > Key: WFLY-6784 > URL: https://issues.jboss.org/browse/WFLY-6784 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radim Hatlapatka > Assignee: Ingo Weiss > Priority: Critical > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client. > There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-646: -------------------------------- Note: Pull request in header is sufficient to fix the problem, but to have green subsystem tests, following subsystem pull request is need: https://github.com/wildfly-security/elytron-subsystem/pull/240 (Changed exception, which is thrown when client-auth was not provided.) > Unable to setup CLIENT_CERT authentication with elytron. > -------------------------------------------------------- > > Key: ELY-646 > URL: https://issues.jboss.org/browse/ELY-646 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate. > In log you there is: > 1. Server send request for certificate > {code} > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities: > ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client> > {code} > 2. And client responds with empty certificate chain. Without asking for certificate > {code} > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty> > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** > {code} > I am attaching: > * server.log - server log with -Djavax.net.debug=all turn on. > * 2wayTLS.pcap - wireshark recording of port 8443 > * secured-app - tested application -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Fix Version/s: 11.0.0.Alpha1 > CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. > The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Description: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. The effects are especially missing client mappings and broken session stickiness. was: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. > CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. > The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7242) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7242: ------------------------------------ Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split Key: WFLY-7242 URL: https://issues.jboss.org/browse/WFLY-7242 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final, 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Critical Fix For: 11.0.0.Alpha1 One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 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 September 2016