Forum @ SIB Visions

Hi,

Is it possible for the user to open/force open work screens in new windows?

regards
nobrega

You mean as new tab or browser window?
No, this isn't supported out-of-the-box.

Sure, it's possible to open a new browser tab or frame with a specific URL. If you bypass the login by e.g. auth-key or SSO and set the welcome screen, it would be possible to implement such requirement easily.

Or did you mean internal frames?

We mean in a new tab on the same browser. Our customers require that some workscreens are always open to be able to switch fast between them.

We can't see how to implement this, is this documented somewhere?

Ok, clear.

This use-case is not documented because it's not related to JVx or the VaadinUI. It's a general SPA problem. Maybe the preserveOnRefresh option is a good solution, see here.

Hi,

To clarify, what we want is for the user to be able to open workscreens of the same application in a separate browser tab.

Ideally we would have a property on the workscreens themselves (specific workscreens would always open in new tabs), and/or we would be able to do something like:

Code: Select all

getApplication().openWorkScreen("...WorkScreen", Modality.NewWindow, ...);


We managed to add an Hyperlink on a test workscreen that when clicked "pops up" that same workscreen in a new tab. The idea would be to add a link like this to all workscreens so user could open the screen on a new window, if he so desires.

Unfortunately vaadin is assuming the new windows belongs to a new session, instead of reusing the current session by looking at the current authentication cookies (?).

We are trying to research why is this happening, almost all information we find states that the default behaviour of vaading is opening the new tabs in the same session:

"Vaadin uses a cookie to identify user's session id. Browsers share cookies between tabs thus the session is shared between tabs. This is almost always the wanted behavior. "

With our preserveOnRefresh option, it's possible to open the same application in different tabs - with same state and UI.

If you want a different UI in different tabs, it means that you need a new session. The problem is not the session, it's the UI instance. Vaadin is able to cache multiple UIs in one session.

If you want to show one window in a new tab and only this window, you'll need a new UI instance because the same UI has the same appearance. You can't use one UI and have a different appearance in different tabs.

Your requirement can be implemented, but this means that you have 2 different UIs - like 2 different logins. This will create a new db connection per UI.

To show different work-screens or the same work-screen multiple times, is possible - as internal frames/windows. If you switch your application to legacy mode, it will show frames....

Examples (search for legacy):

https://blog.sibvisions.com/2015/10/21/ ... -anywhere/,
https://blog.sibvisions.com/2014/09/17/ ... nt-styles/

But, it's not possible to show the same application instance with different windows in different tabs. A vaadin application runs on server-side and the browser is the display.

There's a difference between a website and a Single Page Application. Linking is possible but means a new UI for every tab....

Hi,

Thank you for explaining the technical details/challenges behind our request, it helped us in finding a solution.

Since you have a single page application architecture, opening a workscreen in a new window while remaining connected to the same application object would make no sence. Our main issue, however, is not requesting user for its credentials again. The fact that the application object is shared, or not, is just a detail.

Testing revealed that although new ProjX application objects are created for each login they actually share the same vaadin session object (if opened on a new tab of the same browser instance). With this in mind, we did the following:

- After a successful login, we store additional information on vaadin session.
- On initial login process, we check for this information, set user name and skip authenticating user again.
- On logout we close vaading session to force closing all open applications that are using the same session.

It seems to work, we are still checking if there are any issues with this solution.

Regards.

Usually, this should be done with a custom security manager... Storing the password isn't the best, but sure a valid solution.

It's possible to use our login-key mechanism or create a key in your db after every login and use this key as long as the session is not closed.... The security manager could check the key and bypass authentication. There are different solutions to implement such a request. It depends on your needs and what the application should look like. It's possible to hide menu/toolbar/navigation and only show the screen.... Or use a custom user with specific roles or an anoymous user.

We ususally solve the problems for every technology and not only for vaadin, but it's in your hands

Hi,

We were already using a custom security manager, and that is what we have also used to achieve "autologin". We don't need to store anything on DB, vaadin session takes care of that.

The only issue at the moment is handling user logout by timeout. We can't allow a timeout on one of the applications/TABs to logout the user on all tabs, while at the same time an user logout must logout the user from all application/tabs.

We were trying to use session time out (and disabling application timeout) to achieve this, but there seems to be an issue with it. We are testing under tomcat with 30 seconds session timeout and although we keep switching workscreens every 10 seconds or so, eventually session expires.

Do you know of any issue related to session timeouts?

There seems to be an issue with session timeout and websockets. Requests sent over web sockets do not "access" the http session and thus do not extend the session expiry date.

We ended up having to code our own "session" timeout mechanism.

Thanks for the help.

No this is not right.

Our session timeout works, but it requires explicit configuration, e.g. Session Timeout After User Inactivity

We support session timeout and application timeout. Both was tested and works well.