[Question] Jakarta Faces 4.0.9 on multiwar-deployment in tomcat, possible NPE when a stale cookie exists #5552
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
porting from here by request:
Hey. So, I spent the last days wrapping my head around an error, which I hopefully solved by now, but wanted to ask if this is potentially a bug in the internals, too, so here's an Issue.
First of all, a bit about my context and setup:
The Problem:
Sometimes (not deterministic) after restarting my dockerized setup, I was not able to log in. The flow was like this:
First, the login.xhtml shows the credential form
Then, when submitting, an
f:viewactionredirects to loginsuccess.xhtml which on successful login in turn redirects (via submitting a form using JS after adding params to the form, before you ask: I didn't write this, I'm just here to try to navigate the mess ;) ) to another oauth.xhtml, bundled in gui.war - which again logs in (multiple loginmodules, chosen at runtime, think oauth, saml, depends) and should redirect in the end to a dashboard.xhtmlNow this worked 98% of times, but sometimes when restarting the dockerized env, I got an JSF1094 error, that showed up for me with the error message
I looked up this error, but could only find JSF1094 errors with other error messages, and talking about using myFaces as a solution which i declined, as this was seemingly too big a task, adding to the effort and would possibly introduce other sideeffects.
After trying out multiple non-working JSF parameters like
enableFlash=false(because tha app itself does not use flash externally - result: no effect at all) orforceAlwaysWriteFlashCookie=true(bc i thought maybe it is not written but should be, result: no effect, but btw thanks BalusC for this page which by now seems to be the only page listing the available params) , I tried to add a ServletFilter removing the CSFCFC cookie but the error came back again afterwards (spoiler: Might have been my misunderstanding of what's going on there). I also tried to use a setTimeout with 500ms on the 2nd loginsuccess.xhtml js-redirect, thinking that a staleFlashInfoManagermight still be floating around causing this error. All to no effect, bc still in the second POST from oauth.xhtml, I got this exception in the log:So, here flashInfo is null.
The workaround:
I was able to just hit enter on the oauth.xhtml, afterwards re-opening the /Login in the browser (login.xhtml) again and re-login and got successfully logged in. Afterwards, the error was gone for some time. As this unblocked me at dev time, this was surely nothing to send into prod. So, I digged further as the error started happening again.
Long story short:
After a lot of understanding and internal debugging, I think I found the problem. I summarized my debug-findings here in this picture:
I found that the FlashInfoManager used in
loggingGetPhaseMapForReadingthat it gets fromgetCurrentFlashManagerhas this state (from an exported debug logging):so it is not null, but internally it seems that it doesn't have a valid state. That's because
decryptgets invalid values in this for-loop - which should have an error msg that would've spared me a lot of headaches, but somewhere in between that got lost / nulled.My debug logs showed me what was going on, one byte had a negative value, and the exception was thrown.
So... as you can see in the picture, I am not 100% sure I solved the bug by adding a restart-surviving AES256-encrypted private key to the web.xml's of both modules, but as of now the error didn't happen again, so yay, I ... guess?
Nevertheless I wanted to ask if this execution path should be possible, so here's the ticket. My expectation would've been that
a) doFinal throws an exception if the cookie is not decryptable
b) the error would've shown the error message hinting to the problem (I spared myself to find out why it didn't up until now)
c) the checks in ELFlash would've really checked that the Manager is usable, not just != null
d) a documentation that would've mentioned that it is a good practice in some circumstances to add a private key (if it actually is, so no offense meant here, I am just very insecure here currently)
I hope this is somewhat understandable and also hope someone could answer and assure me that I did the right thing, because to this day (as you can see in the last square in the picture) I am not 100% sure I fixed the problem. Happy to provide you with more information, if needed, but for now I think what I wrote here is more than enough and hopefully someone reads through it. Thanks! 👍
edit: My confidence that adding the key actually solves this hard-to-recreate Bug just went to near 100%. I added a different secretkey value via web.xml, and the same error as before appeared. Then I left the loginpage open (so I have the old cookie still) and restarted again with the old static key, and it immediately worked again. So now I can deterministically reproduce the problem, and solve it by using the other key again. Which assures me that my fix is actually the fix :)
The text was updated successfully, but these errors were encountered: