Restore UI after login

I made an app in V23 with Spring Boot. I have routes in a menu that open their view on tab (I use a customized version of the PagedTabs made by Alejandro Duarte - thanks for that). The tabs stay open (until I close them manually in the browser or from code) and I can switch between views by clicking on the appropriate tab. Some of routes need authentication, while others don’t. We use our own authentication module (another Spring Boot module, our Auth Server). I successfully forward to the login page (/login from the Auth Server) the requests when authentication is needed (i made the forwarding in the beforeEnter() method). Everything seems great. The problem is when I redirect back to the Vaadin app from the Auth Server, a new UI is created.
My question is how can I persistate the UI or better if I could keep it (prevent to Vaadin makes a new one)? I can persitante the tabs or the main layout (the main layout it’s the parent route which holds the tabs too), but when I want to add the persistante and loaded tabs to the mainLayout it says “Can’t move a node from one state tree to another…” blablabla, the usual errors. I understand the error, cause the main layout or the paged tabs still attached to the previous parent component.
Is there a way to solve this problem? I tried it with and without @PreservedOnRefresh, but since a new UI is created it’s not related to this - if i’m right.
Any help would be great, thanks in advance!

Make sure your Views and Components aren’t implemented as singleton scoped component

Thanks for your hint, but I don’t understand how is related to the scopes. The UI will be created independently from the scopes, am I right? Or If the views (the paged tabs and the routes’ view) have a vaadin session scope it will be reused for the new UI? (Because - i didn’t mentioned - The vaadin session will be the same all the time, only the UI modifies).

UI Components can’t be session scoped or higher. The highest they can have is UI / RouteScoped. Anything higher is going to create the exception you have seen. Views / UI Components can’t be shared between UIs, Sessions or Users.

So there is no solution? Can’t I keep the previous UI after login? (I cannot share my code, because it’s too bulky).

I’ve no idea what you have build nor what exactly you mean that sentence.

I don’t think it’s possible or easy to keep the UI when the session is closed. if a user is disconnected you do not want to reuse the ui later. You want to clean it for security/memory reason.

The session isn’t closed, I have only one VaadinSession which remains all the time. “Only” a new UI has created.

I save the first UI in the VaadinSession and when the new UI is initialized (in addUIInitListener) I get the first UI from VaadinSession and call UI.setCurrent(firstUI), but after that when the ParentRoute (my MainLayout) is creating I still see the second UI when calling UI.getCurrent(); I didn’t know what I’m doing wrong.

“Moving” UIs like this isn’t supported.

It’s sad, but I accept it (there’s nothing else I can do anyway). :slightly_smiling_face:
Thanks both of your support!

You have two ways of archive this:

  • work with Serialization to store the session information (and get a lot of problems on the road)
  • try to store the current state of the UI in some custom way that can “rebuild” the current state of the UI… not sure how complex your UI is, but normally the user has navigated somewhere in your app, opened business objects and worked with them - those information based on unique identifiers could be stored and used to build the UI again

For the 2nd approach: these UI / view states and settings should stored in the VaadinSession’s attribute?

I personally would store them in a database. Not sure what’s longer living in your case… the HttpSession should be a live longer if that matters (can be accessed by VaadinSession::get"Something")

VaadinSession.getSession() (it’s a WrappedSession but i think ite a HttpSession)
The problem with the DB is that I don’t know when to purge the old data…
As you pointed out it’s a hard topic, with so many question and pitfall. It doesn’t really worth the hassle.
Okay thanks. I postpone this development and if the customer really wants this sh1t I will struggling with this.

The last sentence sounds like the best reason to postpone - don’t do expensive sh1t nobody has asked for, it’s going to cost you even more later on while maintaining the application. :sweat_smile:

I’ve already spent too many days with this and making spagetti and hack code for the workarounds, but it’s enough. It’s time to stop :slightly_smiling_face: