Hello again,
thanks for the quick answer.
Unfortunately, I cannot downgrade to find out if 2.3.7 caused the issue
because - as mentioned - we only see the behavior in production, and I
can't risk having known unpatched vulnerabilities in production.
For the "test on your side if it works" part, I need to check with
operations, but assuming it is a one-liner I can put on top a clean
2.3.8 I should get the waiver to have it in production.
Did you think something like:
diff --git
a/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java
b/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java
index 66d7cf639..17ee05b4e 100644
---
a/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java
+++
b/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java
@@ -106,7 +106,7 @@ public class CDIManagedBeanHandlerImpl extends
ViewScopeProvider
FacesContext facesContext = FacesContext.getCurrentInstance();
if (facesContext != null)
{
- if (facesContext.getExternalContext().getSession(false) !=
null)
+ if (facesContext.getExternalContext().getSession(false) !=
null && CDIUtils.isSessionScopeActive(beanManager))
{
if (isViewScopeBeanHolderCreated(facesContext))
Cheers,
Juri
On 3/5/21 2:54 PM, Thomas Andraschko wrote:
this is also explained here:
https://github.com/apache/myfaces/blob/2.3.x/impl/src/main/java/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.java#L187
in think the CDIManagedBeanHandlerImpl.java#
<https://github.com/apache/myfaces/blob/2.3.x/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java#L113>onSessionDestroyed
should check if SessionScoped exists before getting the bean holders.
A PR would be great and a test on your side if it works.
Am Fr., 5. März 2021 um 14:45 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:
the problem and described is actually here:
https://github.com/apache/myfaces/blob/2.3.x/impl/src/main/java/org/apache/myfaces/cdi/impl/CDIManagedBeanHandlerImpl.java#L113
on the one hand, we rely on @PreDestroy on ViewScopeBeanHolder, on the
other hand we manually invoke the getViewScopeBeanHolder().destroyBeans();
but the ViewScopeBeanHolder is SessionScoped, which doesnt exist in MyFaces
HttpSessionListener#onSessionDestroyed.
i think thats just a bug.
Am Fr., 5. März 2021 um 14:21 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:
This could be the reason:
https://issues.apache.org/jira/browse/MYFACES-4353
Am Fr., 5. März 2021 um 14:19 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:
Can you try to find the version which introduced it?
Am Fr., 5. März 2021 um 13:57 Uhr schrieb Juri Berlanda <
juri.berla...@tuwien.ac.at>:
Hello,
we recently upgraded to MyFaces 2.3.8 due to the CSRF vulnerability
reported here late February. We were on 2.3.4 before. Since then we see
an insane amount (i.e. 100000+ per day) of "SessionScope does not exist
within current thread" in our logs, like:
15:46:41.421 ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/events]
- Session event listener threw exception
javax.enterprise.context.ContextNotActiveException: WebBeans context
with scope type annotation @SessionScoped does not exist within current
thread
at
org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:329)
~[openwebbeans-impl.jar:2.0.12]
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:89)
~[openwebbeans-impl.jar:2.0.12]
at
org.apache.webbeans.intercept.SessionScopedBeanInterceptorHandler.getContextualInstance(SessionScopedBeanInterceptorHandler.java:76)
~[openwebbeans-impl.jar:2.0.12]
at
org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:71)
~[openwebbeans-impl.jar:2.0.12]
at
org.apache.myfaces.cdi.view.ViewScopeBeanHolder$$OwbNormalScopeProxy2.destroyBeans(org/apache/myfaces/cdi/view/ViewScopeBeanHolder.java)
~[?:2.3.8]
at
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.onSessionDestroyed(CDIManagedBeanHandlerImpl.java:113)
~[myfaces-impl.jar:2.3.8]
at
org.apache.myfaces.webapp.ManagedBeanDestroyerListener.sessionDestroyed(ManagedBeanDestroyerListener.java:201)
~[myfaces-impl.jar:2.3.8]
at
org.apache.catalina.session.StandardSession.expire(StandardSession.java:801)
[catalina.jar:9.0.22]
at
org.apache.catalina.session.StandardSession.isValid(StandardSession.java:659)
[catalina.jar:9.0.22]
at
org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:573)
[catalina.jar:9.0.22]
at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:558)
[catalina.jar:9.0.22]
at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5536)
[catalina.jar:9.0.22]
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1353)
[catalina.jar:9.0.22]
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
[catalina.jar:9.0.22]
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1357)
[catalina.jar:9.0.22]
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1335)
[catalina.jar:9.0.22]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[?:?]
at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
[tomcat-util.jar:9.0.22]
at java.lang.Thread.run(Thread.java:834) [?:?]
We also upgraded Tomcat to 9.0.46 and OpenWebBeans to 2.0.21 trying to
fix the problem - without success. We are not sure what causes the
issue. We assume it has something to do with expired cookies being sent
to the server, but we are not sure that would sum up to the amount we
see. Also, we can't seem to be able to reproduce it on anything but
production system.
JSF stack:
* Tomcat 9.0.46
* OpenWebBeans 2.0.21
* MyFaces 2.3.8
* DeltaSpike 1.9.3 (not sure if relevant)
Any hint, help, or suggestion on debugging and narrowing down the issue
is very much appreciated. If more information is needed, feel free to
ask. I'm not sure what's relevant, so I don't really know what to add
here.
Cheers,
Juri
