[JBoss JIRA] (WFLY-13732) Review current support for OAuth2
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13732:
---------------------------------------
Summary: Review current support for OAuth2
Key: WFLY-13732
URL: https://issues.redhat.com/browse/WFLY-13732
Project: WildFly
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
We presently have support for OAuth2 within our SASL authentication mechanisms to enable tools such as the CLI to make use of an authorization server to obtain an access token.
We should review what else is presently available for OAuth2 for applications within the application server and what we should be doing, especially in the context of confidential clients.
Our implementation of a Bearer HTTP authentication mechanism does challenge but I don't believe all do so to avoid round trips, additionally additional information may be required such as which authorization server to contact and names of relevant scopes etc..
Can anything be done to automate the redirection to the client if required?
How about storage of tokens, either access or refresh tokens? What do they relate to?
For a client credentials grant should the tokens be stored in possibly the credential store? But maybe they relate to a single application only.
For the resource owner grants do they live just within a session? Could they be associated with the current SecurityIdentity for future use.
Overall this task is to understand where we are and where we could go.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS commented on WFLY-12815:
----------------------------------------------
:) Many thanks.
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13697:
-----------------------------------
[~michpetrov] Yes, they share the same cause and marking as dup is fine. I'm not actively working on it. So if you have ideas, feel free to explore and take it.
> JBoss CLI can't find java:app/AppName
> -------------------------------------
>
> Key: WFLY-13697
> URL: https://issues.redhat.com/browse/WFLY-13697
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Management
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: José Fernando Tepedino Martins
> Assignee: Michal Petrov
> Priority: Minor
> Labels: CLI, JNDI
>
> With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
> For example, a job listener or other job artifact with the following code
> {code:java}
> @Resource(lookup="java:app/AppName")
> private String applicationName;{code}
> or
> {code:java}
> private String applicationName;
> @PostConstruct
> protected void initialize() throws NamingException {
> applicationName = InitialContext.doLookup("java:app/AppName");
> }{code}
> when the batch job is started from JBoss CLI, the following error will be logged:
> {code:java}
> javax.naming.NameNotFoundException: java:app/AppName
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13719:
-----------------------------------
[~soul2zimate] can you evaluate docs impact and update these fields?
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13719?page=com.atlassian.jira.plugi... ]
Cheng Fang reassigned WFLY-13719:
---------------------------------
Assignee: Chao Wang
> Error deploying EJB in WildFly when using @EJB
> ----------------------------------------------
>
> Key: WFLY-13719
> URL: https://issues.redhat.com/browse/WFLY-13719
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 20.0.1.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Major
> Attachments: reproducer.zip
>
>
> The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
> ~~~
> public class PleaseIgnoreMeThanks
> { @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
> ~~~
> The issue seems to be on the @EJB annotation.
>
> Generated error:
> {code:xml}
> 10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
> at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
> at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
> at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
> ... 8 more
> ~~{code}
>
> !moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-12815:
--------------------------------------
I've creating a tracking issue for upgrade to newer version of Weld, see WFLY-13731.
Resolving that issue will also bring this fix into WFLY. Not sure what is the correct Jira workflow in this case, but I suppose we keep this issue open until WFLY-13731 resolves.
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFLY-13731) Upgrade Weld to 3.1.5.Final
by Matěj Novotný (Jira)
Matěj Novotný created WFLY-13731:
------------------------------------
Summary: Upgrade Weld to 3.1.5.Final
Key: WFLY-13731
URL: https://issues.redhat.com/browse/WFLY-13731
Project: WildFly
Issue Type: Component Upgrade
Components: CDI / Weld
Affects Versions: 20.0.1.Final
Reporter: Matěj Novotný
Assignee: Matěj Novotný
Fix For: 21.0.0.Beta1
Tracking issue for Weld component update to 3.1.5.Final.
Note that at the time of issue creation, that given Weld version is not yet out, it is currently scheduled for Aug 12.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months