How to use dynamic context paths with session segregation?

I want to serve multiple customers with one Vaadin application. My current approach (although I’m very much open for improvements) would be to have every user log in under a different context path such as
and so on. It should be possible to add new customers at runtime so I cannot enter these paths in the web.xml.

I probably need to register some other servlet that matches all paths and relays the requests to the appropriate Vaadin servlet. But then I need a way to tell Vaadin that it is running under a specific context path and that it should ignore all sessions for another context path.

Do you have any suggestions how this might be done?

Hello Werner,

I think that you are using REST web services.
Firstly, register you vaadin servlet with context path /, which brings all urls with
if you have custom context path like
then register you context path for two paths [b]

in your web.xml.

Then comes the next step -
In the


method of your UI class use
on the VaadinRequest Object. which gives you if the he is customer1 or customer 2 etc. Once you get this go ahead with you business logic.

Please let me know if this doesnt solve your problem.

Hi Krishna,

thanks for your answer.

I am not using REST at all. This is a normal Vaadin application for multiple customers (or tenants) where each customer should have his own path.

I already thought along those lines. My current problem is that if customer1 logs in under
and he changes the path to
he is still logged in and can access the data of another user. However I’m starting to think this should not be solved within Vaadin. We use Spring Security for securing the application and I guess I have to teach it to use different users for different URL paths.

Hello Werner,

Firstly, Is there any specific reason why you are not using Post instead of GET? With that one cannot modify the url.
Secondly, you can do some thing like this, Once the user logs in, add certain paramerter to the session(HttpSession or Wrapped session) like loggedInUser=Customer1 and in your UI class compare the context path with that of loggedInUser in WrappedSession.

If I were you, I would do something like this, Once the user logsin, I would set a certain Parameter called LoggedInUser in the session and No details of the user would be displayed in the url like


instead it would be something like




Hi Krishna,

yes, I’m evaluating this solution right now. Putting the name of the tenant in the session would be better. However I need the tenant identifier (customer1) in the URL in the login form. Otherwise I cannot authenticate the user. The current design has no data shared between tenants (including login information) so I have to select the correct tenant first, then authenticate the user. After that the tenant identifier might just as well reside in the session.

The reason I wanted to put the tenant identifier in the path of the URL is that I thought this would simplify things. Turns out it doesn’t. :slight_smile:

Of course, another solution would be to add another field to the login form where the user has to provide the name of the tenant, e.g., company name but I think this would not be as user friendly as simply clicking a link and providing credentials. Still another possibility would be to have login information in a single shared table but this a) would require unique user names over all tenants and b) might run afoul of some data security laws.

All in all this seems to be more of a Spring Security/Hibernate problem (that’s what we’re using) instead of a Vaadin problem.

Hello Werner,

Why don’t you try some thing like this -
Ask the user to enter the url some thing like this
like you were doing

Based on the tenant info, take the user to a login page and authenticate him, once authenticated place all the required values in the session and redirect him to custom Vaadin Url(So that this changes the context path) .This would solve the problem.

For information regarding on how to place the required info in session after authentication, please have a look at


or some thing similar class in Spring Security.

I could help you if with that if you could attach a stripped down version/Sample of your application