Application using both http and https


Is there any possibility to run vaadin application which switchs from http to https and vice versa? Lets say user is currently in View A which is HTTP. User navigates to View B and that view is HTTPS.

My own feeling is that this is not possible. If this is possible, how this can be achieved? Any workarounds? We have some views that has significantly more traffic. We don’t want to use HTTPS in those views

A site being a https or http is defined by the server it is deployed on. So this is not Vaadin specific.
So you’d have to create two seperate Applications that are deployed on two seperate servers with one having ssl enabled and the other not. Then you could try to “connect” the two applications with iframes and Links, …
This will be quite a lot of work and will come with additional problems as most browsers will probably block http to https calls and vice-versa.
So think about if that is worth it.

It should be possible with different HttpConstraints (if you use an JSR 196 AuthModule) to automatically swap from HTTP to HTTPS , it will be tricky to do this with one UI though, since the view is ussually specified in the URI Fragmen, and going from HTTPS to HTTP I’m not so sure…

Easiest way would be to map two UI’s ( one with transportGuarantee = ServletSecurity.TransportGuarantee.CONFIDENTIAL ) one with out.

@WebServlet(... urlPatterns = {"/secure/*"})
@ServletSecurity(value = @HttpConstraint(rolesAllowed = {"STAFF", "RESELLER"}
    ,transportGuarantee = ServletSecurity.TransportGuarantee.CONFIDENTIAL)

you could do the same in the web.xml


Restrict the views to the different UI’s

@com.vaadin.cdi.CDIView(supportsParameters = false, uis = {SecuredUI.class}, value = SecureViewImpl.NAVIGATION_NAME)
class SecureViewImpl {

@com.vaadin.cdi.CDIView(supportsParameters = false, uis = {UnSecuredUI.class}, value = UnSecureViewImpl.NAVIGATION_NAME) @RolesAllowed({"STAFF","RESELLER"}) class UnSecureViewImpl { .. } But your navigation between the secured and ‘un-secured’ views would have to be pretty specific ( Page.setLocation )

As Marius noted , the browsers will complain (or block) if you mix http and https resources in your app.

It is much simpler to simply enfore everything to be https via the HttpConstraint , at the very least once your transport is HTTPS you should stay on HTTPS.

Agree with Petrus…the norm today if you have an SSL cert is to always use HTTPS. There’s no real benefit to insecure connections anymore as search engines can index HTTPS just fine, and in fact there’s a preference for HTTPS by Google’s bot I think. The “overhead” of SSL is overblown unless you are a hugely popular site, but then you should be able to afford a good SSL setup.

Thanks for your answers. Those point me to right direction.

I tried navigation with that Page.setLocation. Well that transition to HTTPS → HTTP itself works just fine, but it still spawned new problems. It seems that moving from HTTPS to HTTP, new session is created. I think I can deal with that but another problem is much more severe. The Application gets loaded just fine when making the transition, but none of the components respond to user actions. Like pushing buttons or anything - nothing happens. I’m still using single UI

In developer tools, when trying to do something with the app, these lines arrives to the console:
WARNING: Trying to invoke method on not yet started or stopped application

So the app is getting into some error state after the transition. Any idea what is happening? Googling that errror message doesn’t give much answers

We use the JSR 196 AuthModule to ensure the client uses HTTPS ( and it will transition from HTTP to HTTPS automatically on first request ), so I have not encounterd the multiple sessions issue you have.

The issue of components not responding sounds like a Push issue, Try to disable Push or configure it to LongPolling or it might simply be an issue that is not logged properly.

I actually got this working! Wooo!

The reason why whole application went into error state was I had some bugs in navigation logic. Because of the bug, I called Page.setLocation() multiple times in a row. Fixed that and now everything is working.

Thank you all for the help!