[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly, and is missing transformer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2474:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1029938|https://bugzilla.redhat.com/show_bug.cgi?id=1029938] from ON_QA to VERIFIED
> Security subsystem does not handle acl's module properly, and is missing transformer
> ------------------------------------------------------------------------------------
>
> Key: WFLY-2474
> URL: https://issues.jboss.org/browse/WFLY-2474
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> <acl>
> <acl-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </acl-module>
> </acl>
> {code}
> becomes
> {code}
> <acl>
> <login-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </login-module>
> </acl>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1813:
---------------------------
Fix Version/s: 3.4.4
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
> Key: JGRP-1813
> URL: https://issues.jboss.org/browse/JGRP-1813
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Environment: Windows 7
> Reporter: Brett Donahue
> Assignee: Bela Ban
> Priority: Minor
> Labels: EOFException, JDBC_PING,, corruption
> Fix For: 3.5, 3.4.4
>
>
> heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
> at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
> at org.jgroups.util.Util.readAddress(Util.java:929)
> at org.jgroups.util.Util.readAddresses(Util.java:1047)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
> at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
> at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
> at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
> at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
> at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
> at org.jgroups.protocols.Discovery.down(Discovery.java:551)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
> at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
> at org.jgroups.protocols.FD.down(FD.java:307)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
> at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.JChannel._connect(JChannel.java:538)
> at org.jgroups.JChannel.connect(JChannel.java:290)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
> at java.lang.Thread.run(Thread.java:791)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1813.
----------------------------
Resolution: Done
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
> Key: JGRP-1813
> URL: https://issues.jboss.org/browse/JGRP-1813
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Environment: Windows 7
> Reporter: Brett Donahue
> Assignee: Bela Ban
> Priority: Minor
> Labels: EOFException, JDBC_PING,, corruption
> Fix For: 3.5, 3.4.4
>
>
> heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
> at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
> at org.jgroups.util.Util.readAddress(Util.java:929)
> at org.jgroups.util.Util.readAddresses(Util.java:1047)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
> at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
> at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
> at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
> at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
> at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
> at org.jgroups.protocols.Discovery.down(Discovery.java:551)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
> at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
> at org.jgroups.protocols.FD.down(FD.java:307)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
> at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.JChannel._connect(JChannel.java:538)
> at org.jgroups.JChannel.connect(JChannel.java:290)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
> at java.lang.Thread.run(Thread.java:791)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JGRP-1813) JDBC_PING fails to recover for corruption issue
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1813?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1813:
--------------------------------
OK, the row is removed when there's an exception reading it. I'm closing this issue now; please reopen if this still doesn't work.
> JDBC_PING fails to recover for corruption issue
> -----------------------------------------------
>
> Key: JGRP-1813
> URL: https://issues.jboss.org/browse/JGRP-1813
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4
> Environment: Windows 7
> Reporter: Brett Donahue
> Assignee: Bela Ban
> Priority: Minor
> Labels: EOFException, JDBC_PING,, corruption
> Fix For: 3.5
>
>
> heap space was exhausted and issues occurred. In the end, one node in the cluster must have corrupted the data in the JDBC_PING table. From this point onward, our log is full of these (every two seconds):
> 2014 03 23 04:00:25#+0100#ERROR#org.jgroups.protocols.SMP_JDBC_PING##anonymous#Thread-15###Error java.io.EOFException: null
> at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:340)
> at org.jgroups.stack.IpAddress.readFrom(IpAddress.java:226)
> at org.jgroups.util.Util.readAddress(Util.java:929)
> at org.jgroups.util.Util.readAddresses(Util.java:1047)
> at org.jgroups.protocols.PingData.readFrom(PingData.java:163)
> at org.jgroups.util.Util.streamableFromByteBuffer(Util.java:753)
> at org.jgroups.protocols.Discovery.deserialize(Discovery.java:625)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:221)
> at org.jgroups.protocols.JDBC_PING.readAll(JDBC_PING.java:201)
> at org.jgroups.protocols.FILE_PING.fetchClusterMembers(FILE_PING.java:68)
> at org.jgroups.protocols.Discovery.sendDiscoveryRequest(Discovery.java:263)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:227)
> at org.jgroups.protocols.Discovery.findInitialMembers(Discovery.java:208)
> at org.jgroups.protocols.Discovery.down(Discovery.java:551)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:101)
> at org.jgroups.protocols.MERGE2.down(MERGE2.java:185)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:363)
> at org.jgroups.protocols.FD.down(FD.java:307)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)
> at org.jgroups.protocols.BARRIER.down(BARRIER.java:95)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:533)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:575)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347)
> at org.jgroups.protocols.ENCRYPT.down(ENCRYPT.java:925)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.findInitialMembers(ClientGmsImpl.java:201)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:75)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:40)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1052)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:340)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:237)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1024)
> at org.jgroups.JChannel.down(JChannel.java:760)
> at org.jgroups.JChannel._connect(JChannel.java:538)
> at org.jgroups.JChannel.connect(JChannel.java:290)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.startCommunications(ClusterCommunicationsJGroupImpl.java:45)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterCommunicationsJGroupImpl.<init>(ClusterCommunicationsJGroupImpl.java:59)
> at com.sap.mobile.platform.server.cluster.service.impl.ClusterServiceImpl.run(ClusterServiceImpl.java:187)
> at java.lang.Thread.run(Thread.java:791)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (WFLY-3033) Better SSO configuration
by Jason Kim (JIRA)
[ https://issues.jboss.org/browse/WFLY-3033?page=com.atlassian.jira.plugin.... ]
Jason Kim edited comment on WFLY-3033 at 3/27/14 9:52 PM:
----------------------------------------------------------
Disregard this comment. Pull Request at https://github.com/wildfly/wildfly/pull/6080 accomplishes what I was looking for.
was (Author: lc1207h):
I just enabled "path" configuration and am using it on my wildfly. Figured, some others may not want to wait for the update so I put in a pull request. Pull request - https://github.com/wildfly/wildfly/pull/6099
> Better SSO configuration
> ------------------------
>
> Key: WFLY-3033
> URL: https://issues.jboss.org/browse/WFLY-3033
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Reporter: Tin Tvrtkovic
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: single-sign-on, undertow
> Fix For: 8.0.1.Final
>
>
> When enabling Undertow SSO in standalone.xml, the only option to tweak is the cookie domain.
> My life would be made easier by two changes:
> 1) If the domain is not specified, the SSO cookie should have no domain set. This will make the browser apply the domain from the URL being requested. Currently the cookie domain gets populated with a value from the enclosing XML element.
> 2) There's no way of setting the cookie path, which makes this less useful for services on different URLs. I propose adding a path attribute to the SSO XML element, which would set the cookie path. For example:
> <single-sign-on path="/" />
> Right now my workaround is to use my reverse proxy (Apache) to edit response headers and modify the cookie, removing the domain and adding the path. If anyone else needs the workaround:
> Header edit Set-Cookie "^JSESSIONIDSSO=([^; ]+).+" "JSESSIONIDSSO=$1; path=/"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month