[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2227 at 7/2/18 3:28 AM:
--------------------------------------------------------
OK, the reason was that {{AUTH.auth_coord}} has to be set to {{false}} (default: {{true}}), or else the joiner would discard the coord's join response (which carried the join rejection).
However, as the signature of {{AUTH.setAuthCoord()}} changed from returning {{void}} to {{AUTH}}, the setter was not recognized as such anymore and the setting of the attribute {{auth_coord}} failed. I changed this and with {{auth_coord=false}}, I do get the following exception on the joiner (in master):
{noformat}
java.lang.Exception: connecting to channel draw failed
at org.jgroups.JChannel._connect(JChannel.java:904)
at org.jgroups.JChannel.connect(JChannel.java:393)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jgroups.demos.Draw.go(Draw.java:197)
at org.jgroups.demos.Draw.main(Draw.java:160)
Caused by: java.lang.SecurityException: authentication failed
at org.jgroups.protocols.pbcast.ClientGmsImpl.isJoinResponseValid(ClientGmsImpl.java:183)
at org.jgroups.protocols.pbcast.ClientGmsImpl.installViewIfValidJoinRsp(ClientGmsImpl.java:149)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:107)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1063)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
{noformat}
was (Author: belaban):
OK, the reason was that {{AUTH.authenticate_coord}} has to be set to {{false}} (default: {{true}}), or else the joiner would discard the coord's join response (which carried the join rejection).
However, as the signature of {{AUTH.setAuthCoord()}} changed from returning {{void}} to {{AUTH}}, the setter was not recognized as such anymore and the setting of the attribute {{auth_coord}} failed. I changed this and with {{auth_coord=false}}, I do get the following exception on the joiner (in master):
{noformat}
java.lang.Exception: connecting to channel draw failed
at org.jgroups.JChannel._connect(JChannel.java:904)
at org.jgroups.JChannel.connect(JChannel.java:393)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jgroups.demos.Draw.go(Draw.java:197)
at org.jgroups.demos.Draw.main(Draw.java:160)
Caused by: java.lang.SecurityException: authentication failed
at org.jgroups.protocols.pbcast.ClientGmsImpl.isJoinResponseValid(ClientGmsImpl.java:183)
at org.jgroups.protocols.pbcast.ClientGmsImpl.installViewIfValidJoinRsp(ClientGmsImpl.java:149)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:107)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1063)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
{noformat}
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2227 at 7/2/18 3:27 AM:
--------------------------------------------------------
OK, the reason was that {{AUTH.authenticate_coord}} has to be set to {{false}} (default: {{true}}), or else the joiner would discard the coord's join response (which carried the join rejection).
However, as the signature of {{AUTH.setAuthCoord()}} changed from returning {{void}} to {{AUTH}}, the setter was not recognized as such anymore and the setting of the attribute {{auth_coord}} failed. I changed this and with {{auth_coord=false}}, I do get the following exception on the joiner (in master):
{noformat}
java.lang.Exception: connecting to channel draw failed
at org.jgroups.JChannel._connect(JChannel.java:904)
at org.jgroups.JChannel.connect(JChannel.java:393)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jgroups.demos.Draw.go(Draw.java:197)
at org.jgroups.demos.Draw.main(Draw.java:160)
Caused by: java.lang.SecurityException: authentication failed
at org.jgroups.protocols.pbcast.ClientGmsImpl.isJoinResponseValid(ClientGmsImpl.java:183)
at org.jgroups.protocols.pbcast.ClientGmsImpl.installViewIfValidJoinRsp(ClientGmsImpl.java:149)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:107)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1063)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
{noformat}
was (Author: belaban):
OK, the reason was that {{AUTH.auth_coord}} has to be set to {{false}} (default: {{true}}), or else the joiner would discard the coord's join response (which carried the join rejection).
However, as the signature of {{AUTH.setAuthCoord()}} changed from returning {{void}} to {{AUTH}}, the setter was not recognized as such anymore and the setting of the attribute {{auth_coord}} failed. I changed this and with {{auth_coord=false}}, I do get the following exception on the joiner (in master):
{noformat}
java.lang.Exception: connecting to channel draw failed
at org.jgroups.JChannel._connect(JChannel.java:904)
at org.jgroups.JChannel.connect(JChannel.java:393)
at org.jgroups.JChannel.connect(JChannel.java:384)
at org.jgroups.demos.Draw.go(Draw.java:197)
at org.jgroups.demos.Draw.main(Draw.java:160)
Caused by: java.lang.SecurityException: authentication failed
at org.jgroups.protocols.pbcast.ClientGmsImpl.isJoinResponseValid(ClientGmsImpl.java:183)
at org.jgroups.protocols.pbcast.ClientGmsImpl.installViewIfValidJoinRsp(ClientGmsImpl.java:149)
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:107)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1063)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:901)
at org.jgroups.JChannel.down(JChannel.java:668)
at org.jgroups.JChannel._connect(JChannel.java:897)
{noformat}
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-3948:
--------------------------------------
Summary: Potential race condition on deployment of EAR when Class-Path manifest entry is in use
Key: WFCORE-3948
URL: https://issues.jboss.org/browse/WFCORE-3948
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Stuart Douglas
Assignee: Stuart Douglas
Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months
[JBoss JIRA] (WFLY-10653) Degraded performance from ImportedClassELResolver
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10653?page=com.atlassian.jira.plugin... ]
Ilia Vassilev updated WFLY-10653:
---------------------------------
Summary: Degraded performance from ImportedClassELResolver (was: [GSS] (7.1.z) degraded performance from ImportedClassELResolver)
> Degraded performance from ImportedClassELResolver
> -------------------------------------------------
>
> Key: WFLY-10653
> URL: https://issues.jboss.org/browse/WFLY-10653
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Ilia Vassilev
> Assignee: Stuart Douglas
>
> Some cases have shown degraded performance on 7.1 compared to 7.0 because of extra processing overhead added in 7.1's new org.wildlfy.extension.undertow.ImportedClassELResolver.getValue method and its underlying javax.el.ImportHandler.resolveClass calls.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 9 months