[JBoss JIRA] (WFLY-2581) Provide API for use by ejb-security-interceptors quick start.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2581:
-----------------------------------
Description:
The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
• org.jboss.as.domain.management.security.RealmUser.
• org.jboss.as.security.remoting.RemotingContext.
• org.jboss.as.controller.security.SubjectUserInfo
The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
was:The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
> Key: WFLY-2581
> URL: https://issues.jboss.org/browse/WFLY-2581
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> • org.jboss.as.domain.management.security.RealmUser.
> • org.jboss.as.security.remoting.RemotingContext.
> • org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3040:
------------------------------
Component/s: Build System
(was: OSGi)
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3046:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038993
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-3046:
-------------------------------------
A comment taken from BZ:
You need to disable {{use-hornetq-store}} first as {{TransactionSubsystemXMLPersister}} prefers the hornetq store to the jdbc store which is also wrong, see the code snippet below:
{code:java|title=TransactionSubsystemXMLPersister.java}
if(node.hasDefined(CommonAttributes.USEHORNETQSTORE) && node.get(CommonAttributes.USEHORNETQSTORE).asBoolean()) {
..
} else if (node.hasDefined(CommonAttributes.USE_JDBC_STORE) && node.get(CommonAttributes.USE_JDBC_STORE).asBoolean()) {
..
}
{code}
Other possibility would be to enhance {{use-hornetq-store}} and {{use-jdbc-store}} write handlers to disable the opposite option.
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by Ivo Studensky (JIRA)
Ivo Studensky created WFLY-3046:
-----------------------------------
Summary: Not possible change the object store type from hornetq to jdbc via cli commands
Key: WFLY-3046
URL: https://issues.jboss.org/browse/WFLY-3046
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Final
Reporter: Ivo Studensky
Assignee: Ivo Studensky
When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
How to reproduce:
# ./bin/standalone.xml (start eap 6.2.0.GA)
# ./bin/jboss-cli.sh -c (connect to running eap)
# /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
# :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
# /subsystem=transactions/log-store=log-store:read-attribute(name=type)
The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5132) Connection timeout to local port 9999 with clustered AS 7.1.1.Final
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------
Tomaz Cerar <tcerar(a)redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from ASSIGNED to CLOSED
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
> Key: AS7-5132
> URL: https://issues.jboss.org/browse/AS7-5132
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Environment: Fedora 17 on Amazon EC2
> Reporter: Jack Lund
> Assignee: Emanuel Muckenhuber
> Labels: as7, cluster, domain
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.
--
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
11 years, 7 months
[JBoss JIRA] (WFLY-3042) There should be a warning logged if the default value of node identifier has not been changed.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-3042:
-----------------------------------
The point of making it pluggable is that the administrator is in a position to know whether, for example, the IP address is globally unique within their organization, or other such schemes. Likewise with a database or other central registry, the administrator takes on any associated risk as a balance to the effort saved or the risk inherent in manual maintenance of a large environment.
In a domain, in particular, it is actually impossible to set up a unique ID per server in a server group (it uses the profile settings) unless you define a system or environment property on every host which is expanded in that hosts' server (which is potentially an even greater burden, especially if you have a very large number of servers).
> There should be a warning logged if the default value of node identifier has not been changed.
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-3042
> URL: https://issues.jboss.org/browse/WFLY-3042
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Gytis Trikleris
>
> JBoss EAP instance is using the value of node identifier to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if a warning message was logged at startup telling the user to do it.
--
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
11 years, 7 months