Since the migration from Vaadin 6 to Vaadin 7 we have a real problem within the payment process of our web application. Our UI class works also as our main controller and therefore we should preserve our UI instance. We are using a electronic payment service for our payment process.
This eps doesn’t like the window.name attribute which is generated by vaadin. Therefore we have to delete the window.name manually, so that we can redirect to the eps website. But after the redirect from the eps site to our web application, vaadin doesn’t use the old UI instance and creates a new one. This is really bad because we lose a lot of information: logged in user, activiti process handler, cached objects etc…
When we reset the window.name to the old value (removed before the redirect to the website) and make a browser refresh, vaadin uses our old ui instance again. This is the behavior we would like. But the page reload after the redirect doesn’t look nice.
Is there a way to set the window.name attribute (done by Javascript.execute(jquery stuff)) before the creation of a new UI instance? We also tried to use a request handler. But this doesn’t work.
thanks for your quick response. We already use the @PreserverOnRefresh annotation. We retain our UI Instance. But vaadin uses the window.name attribute for this feature. When we set the window.name from (generated name) to “”, to make the redirect to the banking website work (done before the redirect), vaadin reads a new window.name attribute and cant map the window to the old UI instace and creates a new one.
Our Solution so far:
-Store window.name attribute in the session
-set window.name to “”
-make the redirect
-user does the payment, eps website redirects the user to our web application
-vaadin cant find the old generated window.name → creates a new ui instance
-we set the window.name to the old value (from session) and force a browser refresh
-vaadin finds the old window.name → uses the old UI instance (the one, we want to work with).
But this isn’t really satisfying, because a page refresh directly after the redirect looks very messy.
OK. Well, a quick look at the Vaadin code confirms that the window name is the key to the UI. By removing it completely, you are going to stop Vaadin finding it => a refresh is going to be inevitable.
Instead of changing the name before the redirect-to-banking-site, couldn’t you make it valid in the first place? In other words, instead of using Vaadin’s auto-generated name, create your and assign you own name (that the Banking site won’t reject) when the window is created (as opposed to trying to do it dynamically before redirect).
It looks like this is done in the vaadinBootstrap.js script.
But if the banking system will only accept an empty window.name, then as far as I can see, your approach is the only practical one.
(Ps I’ve no knowledge about this - I’ve just looked at the source code)
As far as I can see, a refresh is fairly inevitable here; perhaps you could mitigate by (off the top of my head) on redirect to banking you clear the window.name and store in the session, and then on coming back from banking you redirect to a non-vaadin Servlet that sets the window.name to the stored value and then redirects to the Vaadin app
e.g. Vaadin-App → store-name-and-clear → redirect to banking → Banking App → TempServlet (restore window.name) → Vaadin App
In other words do the restore name outside of the Vaadin app - should be cleaner. But, fundamentally, if the name is the key, and you can’t pass the name through, you can’t avoid some kind of refresh.
So I too stumbled upon this problem when integrating with PayPal. PayPal changes the window.name into “superDaddy”.
Would it be an option to replace the existing UIInitHandler and make a new on that uses cookies instead of the window.name? When using @PreserveOnRefresh and only one UI without different browser windows, I don’t see an issue with this.
Only problem is I don’t know how to plug in a different UIInitHandler…
How are you going to enforce that? The users will not be pleased if simply opening another window or tab will break everything… IMHO it’s much better to simply let go of the idea of trying to preserve the UI instance, and structure your application so that the new UI knows how to continue after the redirect, possibly by explicitly storing the necessary state in the session for a moment.
Would it be a problem that PayPal always resets the window.name to the same thing? I suppose there’s only a very tiny chance of interference when the user is redirected to PayPal twice.
