[JBoss JIRA] (WFLY-3527) Improper noargs constructor assumption leads to NullPointerException
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski resolved WFLY-3527.
--------------------------------------
Resolution: Done
Marshaling fix: https://github.com/jboss-remoting/jboss-marshalling/commit/243f70f5728d8a...
Since: 2.0.0.Beta4
Present: 2.0.2.Final
Comes in WFCORE 3.0.8.Final
> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
> Key: WFLY-3527
> URL: https://issues.jboss.org/browse/WFLY-3527
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.0.0.Final
> Reporter: Randahl Fink Isaksen
> Assignee: Bartosz Baranowski
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final
> …
> 555 topConstructor = current.getDeclaredConstructor();
> 556 } catch (NoSuchMethodException e) {
> 557 return null;
> 558 }
> …
> 563 }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> VALID(true),
> QUESTIONABLE(true),
> INVALID(false);
> private boolean valid;
>
> private Validity(boolean valid) {
> this.valid = valid;
> }
>
> public boolean isValid() {
> return valid;
> }
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> ... 13 more
> Caused by: an exception which occurred:
> in object of type com.intuism.core.settings.EmbeddedSettings
> in field defaultSettings
> in object of type com.intuism.ui.validation.Validation
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-3527) Improper noargs constructor assumption leads to NullPointerException
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-3527:
-------------------------------------
Fix Version/s: 11.0.0.Final
> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
> Key: WFLY-3527
> URL: https://issues.jboss.org/browse/WFLY-3527
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.0.0.Final
> Reporter: Randahl Fink Isaksen
> Assignee: Bartosz Baranowski
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final
> …
> 555 topConstructor = current.getDeclaredConstructor();
> 556 } catch (NoSuchMethodException e) {
> 557 return null;
> 558 }
> …
> 563 }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> VALID(true),
> QUESTIONABLE(true),
> INVALID(false);
> private boolean valid;
>
> private Validity(boolean valid) {
> this.valid = valid;
> }
>
> public boolean isValid() {
> return valid;
> }
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> ... 13 more
> Caused by: an exception which occurred:
> in object of type com.intuism.core.settings.EmbeddedSettings
> in field defaultSettings
> in object of type com.intuism.ui.validation.Validation
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-3527) Improper noargs constructor assumption leads to NullPointerException
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-3527:
----------------------------------------
Assignee: Bartosz Baranowski (was: David Lloyd)
> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
> Key: WFLY-3527
> URL: https://issues.jboss.org/browse/WFLY-3527
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.0.0.Final
> Reporter: Randahl Fink Isaksen
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final
> …
> 555 topConstructor = current.getDeclaredConstructor();
> 556 } catch (NoSuchMethodException e) {
> 557 return null;
> 558 }
> …
> 563 }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> VALID(true),
> QUESTIONABLE(true),
> INVALID(false);
> private boolean valid;
>
> private Validity(boolean valid) {
> this.valid = valid;
> }
>
> public boolean isValid() {
> return valid;
> }
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> ... 13 more
> Caused by: an exception which occurred:
> in object of type com.intuism.core.settings.EmbeddedSettings
> in field defaultSettings
> in object of type com.intuism.ui.validation.Validation
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9072) @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9072?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski resolved WFLY-9072.
--------------------------------------
Resolution: Out of Date
Fixes it seems, same indication has been made bu reporter in downstream. Mentioned test case run and pass.
> @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9072
> URL: https://issues.jboss.org/browse/WFLY-9072
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Michal Jurc
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> Suppose an environment with a chain of three bean invocations:
> {code:java|title=Bean1.java}
> @Stateless
> @Remote(WhoAmI.class)
> @RunAs("Admin")
> @SecurityDomain("other")
> public class Bean1 implements WhoAmI {
> @EJB(beanName = "Bean2")
> private WhoAmI singleton;
> public String getCallerPrincipal() {
> return singleton.getCallerPrincipal();
> }
> }{code}
> {code:java|title=Bean2.java}@Singleton
> @Remote(WhoAmI.class)
> @SecurityDomain("other")
> public class Bean2 implements WhoAmI {
> @EJB(beanName = "Bean3")
> private WhoAmI bean3;
> private String principal;
> @PostConstruct
> public void init() {
> principal = bean3.getCallerPrincipal();
> }
> public String getCallerPrincipal() {
> return principal;
> }
> }
> {code}
> {code:java|title=Bean3.java}@Stateless
> @Local(WhoAmI.class)
> @RolesAllowed("Admin")
> @SecurityDomain("other")
> public class Bean3 implements WhoAmI {
> @Resource
> private SessionContext ctx;
> public String getCallerPrincipal() {
> return ctx.getCallerPrincipal().getName();
> }
> }{code}
> The {{@RunAs("Admin")}} is propagated from {{Bean1}} through {{Bean2.init()}} to {{Bean3}} with Elytron. The EJB3.1 specification does not specify security context of {{@PostConstruct}} method for {{@Singleton}} beans, however with this approach the {{@RunAs}} authorization of initialization of any {{@Singleton}} bean will be determined by its first invoker with Elytron. With legacy security, the {{@RunAs}} authorization of {{@PostConstruct}} method for {{@Singleton}} beans was undefined.
> This is covered by {{org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating}} in WildFly Integration/Basic Test Suite module.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9072) @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9072?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-9072:
----------------------------------------
Assignee: Bartosz Baranowski (was: David Lloyd)
> @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9072
> URL: https://issues.jboss.org/browse/WFLY-9072
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Michal Jurc
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> Suppose an environment with a chain of three bean invocations:
> {code:java|title=Bean1.java}
> @Stateless
> @Remote(WhoAmI.class)
> @RunAs("Admin")
> @SecurityDomain("other")
> public class Bean1 implements WhoAmI {
> @EJB(beanName = "Bean2")
> private WhoAmI singleton;
> public String getCallerPrincipal() {
> return singleton.getCallerPrincipal();
> }
> }{code}
> {code:java|title=Bean2.java}@Singleton
> @Remote(WhoAmI.class)
> @SecurityDomain("other")
> public class Bean2 implements WhoAmI {
> @EJB(beanName = "Bean3")
> private WhoAmI bean3;
> private String principal;
> @PostConstruct
> public void init() {
> principal = bean3.getCallerPrincipal();
> }
> public String getCallerPrincipal() {
> return principal;
> }
> }
> {code}
> {code:java|title=Bean3.java}@Stateless
> @Local(WhoAmI.class)
> @RolesAllowed("Admin")
> @SecurityDomain("other")
> public class Bean3 implements WhoAmI {
> @Resource
> private SessionContext ctx;
> public String getCallerPrincipal() {
> return ctx.getCallerPrincipal().getName();
> }
> }{code}
> The {{@RunAs("Admin")}} is propagated from {{Bean1}} through {{Bean2.init()}} to {{Bean3}} with Elytron. The EJB3.1 specification does not specify security context of {{@PostConstruct}} method for {{@Singleton}} beans, however with this approach the {{@RunAs}} authorization of initialization of any {{@Singleton}} bean will be determined by its first invoker with Elytron. With legacy security, the {{@RunAs}} authorization of {{@PostConstruct}} method for {{@Singleton}} beans was undefined.
> This is covered by {{org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating}} in WildFly Integration/Basic Test Suite module.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2247) [Guided Decision Table] DSL can not contain $ in the definition
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2247:
-----------------------------------
Summary: [Guided Decision Table] DSL can not contain $ in the definition
Key: DROOLS-2247
URL: https://issues.jboss.org/browse/DROOLS-2247
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Affects Versions: 7.5.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Fix For: 7.6.0.Final
The DSL sentences are defined like:
- [when] *definition* = real rule
If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2246) [XLS Decision Table] New Asset Dialogue misses descriptions
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2246:
-----------------------------------
Summary: [XLS Decision Table] New Asset Dialogue misses descriptions
Key: DROOLS-2246
URL: https://issues.jboss.org/browse/DROOLS-2246
Project: Drools
Issue Type: Bug
Components: XLS Decision Table Editor
Affects Versions: 7.5.0.Final
Reporter: Jozef Marko
Assignee: Jozef Marko
Priority: Optional
Attachments: Screenshot from 2017-11-03 10-20-21.png
The attached dialogue shows missing descriptions for table format and file selector.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (DROOLS-2245) [Guided Rule] From Accumulate using a List Field of a Data Object
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2245:
-----------------------------------
Summary: [Guided Rule] From Accumulate using a List Field of a Data Object
Key: DROOLS-2245
URL: https://issues.jboss.org/browse/DROOLS-2245
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor, Guided Rule Editor
Affects Versions: 7.5.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: Screenshot from 2017-11-08 10-23-50.png, Screenshot from 2017-11-08 10-31-41.png, Screenshot from 2017-11-08 10-31-58.png
There is problem if From Accumulate expression iterates over List field of a Data Object.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months