[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
The reason for IP multicast loss is that the application doesn't re-register its multicast groups after an ifdown-ipup cycle.
If you run {{netstat -ng}} before ifdown-ifup and after, the routes to {{224.0.75.75}} (probe) and {{228.8.8.8}} (UDP) are lost.
I need to investigate whether this can be done by JGroups...
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1944 at 8/3/15 12:26 PM:
---------------------------------------------------------
Hmm, if I replace {{MPING}} with {{TCPPING}}, things work ! It seems that multicasting is not re-enabled correctly in ifup... ?
{noformat}
<TCP.../>
<TCPPING initial_hosts="192.168.1.153[7800],192.168.1.154[7800]" />
{noformat}
Even probe.sh doesn't work any longer, at {{224.0.75.75:7500}}
was (Author: belaban):
Hmm, if I replace {{MPING}} with {{TCPPING}}, things work ! It seems that multicasting is not re-enabled correctly in ifup... ?
{noformat}
<TCP.../>
<TCPPING initial_hosts="192.168.1.153[7800],192.168.1.154[7800]" />
{noformat}
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (DROOLS-477) KieScanner is not working as expected
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-477?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-477:
------------------------------------
I believe the issue you're reporting has been fixed with this commit https://github.com/droolsjbpm/drools/commit/ee7dd7c91
Please try again with Drools 6.3.0.Beta2 and check if this fixed your problem.
> KieScanner is not working as expected
> -------------------------------------
>
> Key: DROOLS-477
> URL: https://issues.jboss.org/browse/DROOLS-477
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Environment: Windows 7
> Reporter: Alexander Pykhtin
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta4
>
> Attachments: drools_jar.zip, drools_sample.zip
>
>
> KieScanner is not dynamically updates the rules in a sample application.
> drools_sample is a parent project, drools_jar is its dependency that is expected to be dynamically updated.
> Here is the sample code:
> Scanner scanner = new Scanner(System.in);
> try {
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId = ks.newReleaseId( "com.study", "drools_sample", "0.0.1-SNAPSHOT" );
> KieContainer kContainer = ks.newKieContainer( releaseId );
> KieSession kSession = null;
> KieScanner kScanner = ks.newKieScanner( kContainer );
> boolean repeat = true;
> // go !
> while(repeat)
> {
> kSession = kContainer.newKieSession("ksession-rules_jar");
> Message message = new Message();
> message.setMessage("Hello World");
> message.setStatus(Message.HELLO);
> DynamicFactType dft = new DynamicFactType();
> kSession.insert(message);
> kSession.insert(dft);
> kSession.fireAllRules();
> kSession.dispose();
> String inp = scanner.nextLine();
> if(inp.length() > 0)
> repeat = false;
> else
> {
> kScanner.scanNow();
> }
> }
> } catch (Throwable t) {
> t.printStackTrace();
> }
> scanner.close();
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1944:
--------------------------------
Hmm, if I replace {{MPING}} with {{TCPPING}}, things work ! It seems that multicasting is not re-enabled correctly in ifup (?) !
{noformat}
<TCP.../>
<TCPPING initial_hosts="192.168.1.153[7800],192.168.1.154[7800]" />
{noformat}
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JGRP-1944) jgroups does not recover properly when using UDP after ifdown / ifup
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1944?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1944 at 8/3/15 12:19 PM:
---------------------------------------------------------
Hmm, if I replace {{MPING}} with {{TCPPING}}, things work ! It seems that multicasting is not re-enabled correctly in ifup... ?
{noformat}
<TCP.../>
<TCPPING initial_hosts="192.168.1.153[7800],192.168.1.154[7800]" />
{noformat}
was (Author: belaban):
Hmm, if I replace {{MPING}} with {{TCPPING}}, things work ! It seems that multicasting is not re-enabled correctly in ifup (?) !
{noformat}
<TCP.../>
<TCPPING initial_hosts="192.168.1.153[7800],192.168.1.154[7800]" />
{noformat}
> jgroups does not recover properly when using UDP after ifdown / ifup
> --------------------------------------------------------------------
>
> Key: JGRP-1944
> URL: https://issues.jboss.org/browse/JGRP-1944
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: Linux Ubutun 14.04 where the network cards are configured as bridges:
> auto bridge0
> iface bridge0 inet dhcp
> bridge_ports eth1
> bridge_stp off
> bridge_fd 0
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 3.6.5
>
> Attachments: AutoRecoverMulticast.java
>
>
> When we bring the interface down and back up in a complete (udp.xml) configuration everything *seems* to be fine, however multicast traffic from the node that had the interface brought down is not received by other nodes. The node also doesn't receive any data from the other nodes. No exceptions are logged. I don't think the previous test was done correctly by me ... sorry .
> When we use TCP + MPING we see the stacktraces we had previously with UDP:
> 12:13:51.624 50644 [Timer-3,debug,shockvm-tn3-42192] ERROR unknown.jul.logger - failed sending discovery request
> java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) ~[na:1.7.0_79]
> at java.net.DatagramSocket.send(DatagramSocket.java:697) ~[na:1.7.0_79]
> at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:295) ~[jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.sendDiscoveryRequest(PING.java:61) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.PING.findMembers(PING.java:31) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.Discovery.down(Discovery.java:387) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:382) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321) [jar:rsrc:jgroups-3.6.4.Final.jar!/:na]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> (The exact message differs whether or not the -Djava.net.preferIPv4Stack=true argument is configured)
> A configuration that uses MPING also doesn't recover from ifdown/ifup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-5049) AMQ Artemis does not support slash character used in activation property of MDB
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5049?page=com.atlassian.jira.plugin.... ]
Miroslav Novak moved JBEAP-582 to WFLY-5049:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5049 (was: JBEAP-582)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Alpha6
(was: EAP 7.0.0.DR7)
Component/s: JMS
(was: JMS)
Target Release: (was: EAP 7.0.0.GA)
> AMQ Artemis does not support slash character used in activation property of MDB
> -------------------------------------------------------------------------------
>
> Key: WFLY-5049
> URL: https://issues.jboss.org/browse/WFLY-5049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> When using slash character {{/}} in configuration of artemis messaging subsystem as jms queue name then MDB fails to connect to remote messaging server.
> My settings is following - I have a remote messaging server where queue is defined like
> {code}
> <jms-queue name="queue/crashRecoveryQueue" entries="java:jboss/queue/crashRecoveryQueue"/>
> {code}
> Then there is a server where MDB is deployed. That server configures connection factory
> {code}
> <pooled-connection-factory name="messaging-broker-remote" transaction="xa" entries="java:/RemoteJmsXA" connectors="messaging-broker-http-remote"/>
> {code}
> http connector
> {code}
> <http-connector name="messaging-broker-http-remote" socket-binding="remote-messaging">
> <param name="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> {code}
> outbound socket binding
> {code}
> <outbound-socket-binding name="remote-messaging">
> <remote-destination host="127.0.0.1" port="8280"/>
> </outbound-socket-binding>
> {code}
> and resource reference for ejb subsystem
> {code}
> <mdb>
> <resource-adapter-ref resource-adapter-name="messaging-broker-remote"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> {code}
> The MDB uses ejb-jar with activation properties
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <ejb-jar id="EJBJar_1060639024453" version="3.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> metadata-complete="false">
> <enterprise-beans>
> <message-driven>
> <ejb-name>JMSCrashMessageDrivenBean</ejb-name>
> <ejb-class>org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean</ejb-class>
> <activation-config>
> <activation-config-property>
> <activation-config-property-name>destination</activation-config-property-name>
> <activation-config-property-value>queue/MDBTriggerQueue</activation-config-property-value>
> </activation-config-property>
> <activation-config-property>
> <activation-config-property-name>destinationType</activation-config-property-name>
> <activation-config-property-value>javax.jms.Queue</activation-config-property-value>
> </activation-config-property>
> </activation-config>
> </message-driven>
> </enterprise-beans>
> </ejb-jar>
> {code}
> The server does not show any warning that the connection was not found, just MDB does not receive any message from the queue.
> If I use {{MDBTriggerQueue}} instead of {{queue/MDBTriggerQueue}} the same setup starts working perfectly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-3988) Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3988?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3988:
-----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1206657|https://bugzilla.redhat.com/show_bug.cgi?id=1206657] from ON_QA to VERIFIED
> Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-3988
> URL: https://issues.jboss.org/browse/WFLY-3988
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
> Fix For: 9.0.0.Beta1
>
>
> Given this endpoint:
> {code:java}
> @Stateless
> @WebService(endpointInterface="com.redhat.gss.SecureEndpoint")
> @DeclareRoles({"a","b"})
> @WebContext(contextRoot="/endpoint",urlPattern="/e",authMethod="BASIC")
> public class SecureEndpointE implements SecureEndpoint {
> @RolesAllowed({"a"})
> public String a() {
> return "Success";
> }
> @RolesAllowed({"b"})
> public String b() {
> return "Success";
> }
> @PermitAll
> public String c() {
> return "Success";
> }
> }
> {code}
> One would expect any authenticated user to be able to invoke {{c()}}, but only users with a role found in {{@DelareRoles}} can invoke it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2129:
-----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1206657|https://bugzilla.redhat.com/show_bug.cgi?id=1206657] from ON_QA to VERIFIED
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2129
> URL: https://issues.jboss.org/browse/WFLY-2129
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Environment: Mac OS X
> Reporter: Nicky Mølholm
> Assignee: Jim Ma
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc)
> A simple EJB with a Web service view can illustrate the first problem:
> {code:java}
> @Stateless
> @WebService
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> @PermitAll // <-- This doesn't work
> //@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> // <--- unless you put them on class level
> public String sayHello(String name) {
> System.out.println("******** Greeter.sayHello(" + name + ")");
> return "Hello " + name;
> }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll,@DenyAll,@RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months