Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
I'm looking at increasing the security of my Vaadin App.
Right now, I have a custom built login form. When the user enter his or her username and password, i redirect to the appropriate screen. I am now adding HTTPS to this form for added security.
I wanted to take it one step further if possible, and check authentication on each request, if this is possible. I could store the username and password in a cookie, and authenticate on each request. But my gut tells me this is a no-no.
My other thought is, if I am doing this over HTTPS, then someone can not do packet sniffing to check my session ID, so the above is not necessary. In fact, I think the HTTPS should be enough to prevent any malicious URL hacks.
To avoid session cookie hijacking, some AJAX solutions take the approach of sending a unique id with each request (besides the jsessionid cookie and/or jsessionid in the URL) where it can be validated to ensure nobody else is trying to hijack the session id. I guess the idea is that if the browser has a regular cookie with the jsessionid in it, and you visit a malicious site while still logged in, it could make the request back to the Vaadin server and the browser will automatically send that session id cookie, so it will appear to be from the logged in user. But if you include the extra token in the request, that malicious site won't know the value and cannot send it, too.
Does Vaadin's UIDL have such a built-in mechanism?
If you can assume that the servlet session is secure, then your approach will work fine so long as you remember to invalidate the session when the logoff. It is quite common to store the "logged in user" object in the session to determine if the session is currently authenticated or not, and that does need to occur on every request. We do that in the onRequestStart(HttpServletRequest request, HttpServletResponse response) method of our subclassed Vaadin Application, but there may be other schemes to do it as well.