[JBoss JIRA] (WFLY-7140) Injection with @EJB is not working as expected with CDI (REST) beans
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-7140?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-7140:
------------------------------
Component/s: CDI / Weld
EJB
> Injection with @EJB is not working as expected with CDI (REST) beans
> --------------------------------------------------------------------
>
> Key: WFLY-7140
> URL: https://issues.jboss.org/browse/WFLY-7140
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
>
> The injection with @EJB should work the same way in a Rest service (CDI Bean) as it does in a Servlet.
> @EJB(lookup = "ejb:jboss-ejb-multi-server-app-one/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne")
> is not working correct if used in a CDI Bean in the reproducer example.
> Reproducer can be found here:
> git@github.com:wfink/jboss-eap-quickstarts.git
> BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection
> SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app)
> see ejb-multi-server/README-reproducerEJB-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-623 at 9/20/16 1:54 AM:
---------------------------------------------------------
Ok, so should I change input parameter of this method from "String name" to "Principal" ?
(I dont see way to improve this without API change...)
was (Author: honza889):
Ok, so should I change input parameter of this method from "String name" to "Principal" ?
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Jan Kalina
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-623 at 9/20/16 1:54 AM:
---------------------------------------------------------
Ok, so should I change input parameter of this method (createRunAsIdentity) from "String name" to "Principal" ?
(I dont see way to improve this without API change...)
was (Author: honza889):
Ok, so should I change input parameter of this method from "String name" to "Principal" ?
(I dont see way to improve this without API change...)
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Jan Kalina
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-623) Checking for anonymous principal by name is insufficient
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-623?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-623:
--------------------------------
Ok, so should I change input parameter of this method from "String name" to "Principal" ?
> Checking for anonymous principal by name is insufficient
> --------------------------------------------------------
>
> Key: ELY-623
> URL: https://issues.jboss.org/browse/ELY-623
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Jan Kalina
>
> In {{src/main/java/org/wildfly/security/auth/server/SecurityIdentity.java}}:
> {noformat}
> + if (AnonymousPrincipal.getInstance().getName().equals(name)) {
> + if (! context.authorizeAnonymous(false)) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new AnonymousPrincipal(), null);
> + }
> + } else {
> + if (! (context.importIdentity(this) && context.authorize(name, authorize))) {
> + throw log.runAsAuthorizationFailed(getPrincipal(), new NamePrincipal(name), null);
> + }
> }
> {noformat}
> Only a type check is sufficient to determine if a principal is anonymous. In this fix, the string name "anonymous" takes on a special meaning for the first time, which should not be the case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (LOGMGR-141) StringIndexOutOfBoundsException throw while formatting log with truncation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-141?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-141:
------------------------------------------------
Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1350757|https://bugzilla.redhat.com/show_bug.cgi?id=1350757] from NEW to ASSIGNED
> StringIndexOutOfBoundsException throw while formatting log with truncation
> --------------------------------------------------------------------------
>
> Key: LOGMGR-141
> URL: https://issues.jboss.org/browse/LOGMGR-141
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 2.1.0.Beta1
>
>
> When value in left-justified field is longer than maximum width following exception is thrown:
> {code}
> java.lang.StringIndexOutOfBoundsException
> at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:733)
> at java.lang.StringBuilder.delete(StringBuilder.java:244)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:212)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:302)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:719)
> at org.jboss.logmanager.Logger.log(Logger.java:670)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
> at org.jboss.logging.Logger.logf(Logger.java:2096)
> {code}
> Steps to Reproduce:
> 1. Configure formatter with left-justified field with maximum width:
> {code}
> /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter,value="%d{HH:mm:ss,SSS} %-5p [%c{1.}] [%-20.-20t] %s%E%n")
> {code}
> (in the example above thread name should be truncated to 20 characters, left-justified)
> 2. Write a log from a thread which has a name containg 21 characters or more. During server startup logs are written by "MSC service thread 1-7" thread.
> It seems there is an error in {{org.jboss.logmanager.formatters.Formatters()}} class, line 212. There is:
> {code:java}
> builder.delete(oldLen, overflow + 1);
> {code}
> but should be:
> {code:java}
> builder.delete(oldLen, oldLen + overflow);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7143?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-7143:
------------------------------
Description:
Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
{code:xml}
<mappers>
<simple-permission-mapper name="login-permission-mapper">
<permission-mapping roles="All">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
</permission-mapping>
</simple-permission-mapper>
<constant-role-mapper name="constant-roles" roles="All"/>
</mappers>
{code}
We have to make the default server configuration secure for users.
*Suggestions for improvement:*
* the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
* constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
was:
Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
{code:xml}
<mappers>
<simple-permission-mapper name="login-permission-mapper">
<permission-mapping roles="All">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
</permission-mapping>
</simple-permission-mapper>
<constant-role-mapper name="constant-roles" roles="All"/>
</mappers>
{code}
We have to make the default server configuration secure for users.
*Suggestions for improvement:*
* the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want to be assigned to some principals/roles
* constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
> Unsafe Elytron role/permission mapping
> --------------------------------------
>
> Key: WFLY-7143
> URL: https://issues.jboss.org/browse/WFLY-7143
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
> The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
> {code:xml}
> <mappers>
> <simple-permission-mapper name="login-permission-mapper">
> <permission-mapping roles="All">
> <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
> </permission-mapping>
> </simple-permission-mapper>
> <constant-role-mapper name="constant-roles" roles="All"/>
> </mappers>
> {code}
> We have to make the default server configuration secure for users.
> *Suggestions for improvement:*
> * the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want the permission to be assigned to some principals/roles
> * constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7143) Unsafe Elytron role/permission mapping
by Josef Cacek (JIRA)
Josef Cacek created WFLY-7143:
---------------------------------
Summary: Unsafe Elytron role/permission mapping
Key: WFLY-7143
URL: https://issues.jboss.org/browse/WFLY-7143
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Blocker
Default Elytron configuration assigns role "All" to every user during authentication. If a deployed application uses such the role name for a resource protection, then every authenticated user can access the protected resource. So the security is bypassed then.
The problem is caused by workaround used for mapping "LoginPermission" to all users. It maps role "All" to the users first and then maps "LoginPermission" to this role.
{code:xml}
<mappers>
<simple-permission-mapper name="login-permission-mapper">
<permission-mapping roles="All">
<permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
</permission-mapping>
</simple-permission-mapper>
<constant-role-mapper name="constant-roles" roles="All"/>
</mappers>
{code}
We have to make the default server configuration secure for users.
*Suggestions for improvement:*
* the {{LoginPermission}} mapping should be implicit so everybody has it by default - without specifying it in the server configuration; users should only define cases when they don't want to be assigned to some principals/roles
* constant permission mapper should exist in Elytron subsystem (similar to {{constant-role-mapper}}) so the custom permission can be mapped without workarounds through role-mappings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7139) IllegalStateException: WFLYEE0043: Component is stopped
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-7139?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-7139:
-------------------------------------------
I'm not sure of a more specific exception should be created in this case (such as for example ComponentIsShutdownException) and raised for this particular case. I decided to catch the IllegalStateException and check for the matching message instead.
> IllegalStateException: WFLYEE0043: Component is stopped
> -------------------------------------------------------
>
> Key: WFLY-7139
> URL: https://issues.jboss.org/browse/WFLY-7139
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Labels: clean_undeploy
>
> Occured on client during remote EJB undeploy failover tests. Scenarios:
> eap-7x-failover-ejb-ejbremote-undeploy-dist-async,
> eap-7x-failover-ejb-ejbremote-undeploy-repl-async,
> eap-7x-failover-ejb-ejbremote-undeploy-repl-sync.
> Happened after "Failing node 0 (perf18)" at 2016/08/18 11:59:51:537 and stopped occuring at 2016/08/18 12:06:04:494 just before "Node 3 (perf21) is down".
> Stacktrace from client:
> {code}
> 2016/08/18 11:59:52:694 EDT [ERROR][Runner - 1092] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: WFLYEE0043: Component is stopped>
> java.lang.IllegalStateException: WFLYEE0043: Component is stopped
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:110)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:194)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:383)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 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:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client logs:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clust...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months