[JBoss JIRA] (JBASMP-84) Default packaging types links ejb projects to a mave-plugin project which is ignored by default
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBASMP-84?page=com.atlassian.jira.plugin.... ]
James Perkins moved WFMP-50 to JBASMP-84:
-----------------------------------------
Project: JBoss AS Maven Plugins (was: WildFly Maven Plugin)
Key: JBASMP-84 (was: WFMP-50)
Component/s: (was: Maven Plugin)
Fix Version/s: 7.9.Final
(was: 1.1.0.Alpha11)
> Default packaging types links ejb projects to a mave-plugin project which is ignored by default
> -----------------------------------------------------------------------------------------------
>
> Key: JBASMP-84
> URL: https://issues.jboss.org/browse/JBASMP-84
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Blocker
> Fix For: 7.9.Final
>
>
> The {{org.wildfly.plugin.deployment.PackageType}} static mapping links the EJB packaging type to the {{MAVEN_PLUGIN}} type which by default is skipped for deployments. The proper type needs to be added to the map.
> {code:java}
> static {
> DEFAULT_TYPES = new HashMap<>();
> DEFAULT_TYPES.put(MAVEN_PLUGIN.packaging, MAVEN_PLUGIN);
> DEFAULT_TYPES.put(POM.packaging, MAVEN_PLUGIN);
> DEFAULT_TYPES.put(EJB.packaging, MAVEN_PLUGIN);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-5329 to WFLY-6863:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6863 (was: JBEAP-5329)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.GA)
(was: 7.0.1.CR1)
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6863) Excluded contexts which are not specific to a host should be excluded on all hosts
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6863?page=com.atlassian.jira.plugin.... ]
Radoslav Husar resolved WFLY-6863.
----------------------------------
Fix Version/s: 10.1.0.CR1
Resolution: Done
Resolved with mod_cluster 1.3.3.Final upgrade.
> Excluded contexts which are not specific to a host should be excluded on all hosts
> ----------------------------------------------------------------------------------
>
> Key: WFLY-6863
> URL: https://issues.jboss.org/browse/WFLY-6863
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Tomcat8 (haven't tried elsewhere yet); mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 10.1.0.CR1
>
>
> With the following configuration:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1"
> loadHistory="9"
> loadDecayFactor="2"
> stickySession="true"
> stickySessionForce="false"
> stickySessionRemove="true"
> advertise="true"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> advertiseInterface="10.40.4.50"
> excludedContexts="ROOT,docs,manager,host-manager,examples"
> />
> {code}
> And these contexts in webapps:
> {code}
> clusterbench docs examples host-manager manager ROOT
> {code}
> One expects this output on Mod_cluster manger console:
> {code}
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> It works, unless you configure additional VirtualHosts:
> {code}
> <Host name="LOCALHOST" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>LOCALHOST</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> <Host name="KARM.BRQ.REDHAT.COM" appBase="webapps" unpackWARs="true" autoDeploy="true">
> <Alias>KARM.BRQ.REDHAT.COM</Alias>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h %l %u %t "%r" %s %b" />
> </Host>
> {code}
> result:
> {code}
> Node worker1 (ajp://10.40.4.50:8009):
> Enable Contexts Disable Contexts Stop Contexts
> Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 1,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 100
> Virtual Host 2:
> Contexts:
> /docs, Status: ENABLED Request: 0 Disable Stop
> /manager, Status: ENABLED Request: 0 Disable Stop
> /host-manager, Status: ENABLED Request: 0 Disable Stop
> /examples, Status: ENABLED Request: 0 Disable Stop
> /, Status: ENABLED Request: 0 Disable Stop
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> karm.brq.redhat.com
> Virtual Host 1:
> Contexts:
> /clusterbench, Status: ENABLED Request: 0 Disable Stop
> Aliases:
> localhost
> {code}
> I find this bug being of Critical priority, because it could coax users into believing they excluded certain context while in fact they didn't.
> WDYT? Is it possible to tweak with the Listener's configuration somehow?
> THX.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6864) Subject not populated with groups/roles when authenticated via JASPIC
by James Perkins (JIRA)
James Perkins created WFLY-6864:
-----------------------------------
Summary: Subject not populated with groups/roles when authenticated via JASPIC
Key: WFLY-6864
URL: https://issues.jboss.org/browse/WFLY-6864
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.CR4
Reporter: Arjan t
Assignee: Darran Lofthouse
After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
{code:java}
Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
boolean hasAccess = Policy.getPolicy().implies(
new ProtectionDomain(
new CodeSource(null, (Certificate[]) null),
null, null,
subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
),
new WebResourcePermission("/protected/Servlet", "GET"))
;
{code}
As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
{code:java}
String[] rolesArray = groupPrincipalCallback.getGroups();
int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
if( sizeOfRoles > 0 )
{
List<Role> rolesList = new ArrayList<Role>();
for( int i = 0; i < sizeOfRoles ; i++ )
{
Role role = new SimpleRole( rolesArray[ i ] );
rolesList.add( role );
}
RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
// if the current security context already has roles, we merge them with the incoming roles.
RoleGroup currentRoles = currentSC.getUtil().getRoles();
// *** ROLES ARE ONLY SET HERE ***
if (currentRoles != null) {
currentRoles.addAll(roles.getRoles());
}
else {
currentSC.getUtil().setRoles( roles );
}
}
// *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
// *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
Subject subject = groupPrincipalCallback.getSubject();
if( subject != null )
{
// if the current security context already has an associated subject, we merge it with the incoming subject.
Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
if (currentSubject != null) {
subject.getPrincipals().addAll(currentSubject.getPrincipals());
subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
}
currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6864) Subject not populated with groups/roles when authenticated via JASPIC
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6864?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned WFLY-6864:
-----------------------------------
Assignee: James Perkins (was: Darran Lofthouse)
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-6864
> URL: https://issues.jboss.org/browse/WFLY-6864
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Arjan t
> Assignee: James Perkins
> Labels: jacc, jaspic
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6726) Add help text about jboss.undefinded.host for the wsdl-host attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6726:
--------------------------------------
Fix Version/s: 10.1.0.CR1
Assignee: Claudio Miranda (was: Alessio Soldano)
Resolution: Done
> Add help text about jboss.undefinded.host for the wsdl-host attribute
> ---------------------------------------------------------------------
>
> Key: WFLY-6726
> URL: https://issues.jboss.org/browse/WFLY-6726
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Claudio Miranda
> Assignee: Claudio Miranda
> Fix For: 10.1.0.CR1
>
>
> would be doable to add the text to the
> resource-description of wsdl-url, related to the use of
> jboss.undefined.host ?
> The path
> /deployment=*/subsystem=webservices/endpoint=*:read-resource-description
> I ask that because HAL consumes and exposes the resource-description
> of each attribute and having the help text about the
> jboss.undefined.host in wsdl-host also helps CLI users.
> A suggestion for the text:
> "Webservice endpoint WSDL URL. If wsdl-host is set to
> jbossws.undefined.host, Wildfly uses the requester's host when
> rewriting the <soap:address>"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6862) Add help text about jboss.undefinded.host for the wsdl-host attribute
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6862?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-6862:
--------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9047)
> Add help text about jboss.undefinded.host for the wsdl-host attribute
> ---------------------------------------------------------------------
>
> Key: WFLY-6862
> URL: https://issues.jboss.org/browse/WFLY-6862
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Claudio Miranda
> Assignee: Alessio Soldano
>
> would be doable to add the text to the
> resource-description of wsdl-url, related to the use of
> jboss.undefined.host ?
> The path
> /deployment=*/subsystem=webservices/endpoint=*:read-resource-description
> I ask that because HAL consumes and exposes the resource-description
> of each attribute and having the help text about the
> jboss.undefined.host in wsdl-host also helps CLI users.
> A suggestion for the text:
> "Webservice endpoint WSDL URL. If wsdl-host is set to
> jbossws.undefined.host, Wildfly uses the requester's host when
> rewriting the <soap:address>"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-6862) Add help text about jboss.undefinded.host for the wsdl-host attribute
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6862?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned WFLY-6862:
-----------------------------------
Assignee: James Perkins (was: Alessio Soldano)
> Add help text about jboss.undefinded.host for the wsdl-host attribute
> ---------------------------------------------------------------------
>
> Key: WFLY-6862
> URL: https://issues.jboss.org/browse/WFLY-6862
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: Claudio Miranda
> Assignee: James Perkins
>
> would be doable to add the text to the
> resource-description of wsdl-url, related to the use of
> jboss.undefined.host ?
> The path
> /deployment=*/subsystem=webservices/endpoint=*:read-resource-description
> I ask that because HAL consumes and exposes the resource-description
> of each attribute and having the help text about the
> jboss.undefined.host in wsdl-host also helps CLI users.
> A suggestion for the text:
> "Webservice endpoint WSDL URL. If wsdl-host is set to
> jbossws.undefined.host, Wildfly uses the requester's host when
> rewriting the <soap:address>"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5795:
-----------------------------------
Fix Version/s: 10.1.0.CR1
(was: 10.0.0.Final)
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.1.0.CR1
>
> Attachments: ClusteredTopicTest.java, domain.xml, domain.xml, host-slave.xml, host.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 5 months