How can I reload my page to redirect to an URI Fragment in VAADIN? - redirect

In my Vaadin webapp I have a tipical architecture with login. In some cases, the user can access directly to some resources using Vaadin URI Fragments (http://example.com/#fragment).
When a user tryes to access some resource, If the user has logged in, I take from the URL the #FRAGMENT and I bring him to it.
But if the user has no logged in, when he logs in I used to bring him to the main page using
getPage().open("/", "_self");
but since if I add an URI Fragment, the getPage().open(...) does not work.
Is there any way to redirect the user to a correct URL (URL with UriFragment in my case) from code?

Note that there is a fundamental difference in how navigation is handled in traditional web applications versus single-page applications as implemented with Vaadin. In traditional web applications you navigate through the app by making full HTTP GET-Requests on some path (such as www.example.com/myapp/home). On each such request, a full page reload is performed. You can't do that with Vaadin, as a full page reload means reloading the Vaadin widget set and rebuilding the page layout from the ground up. Therefore, single-page applications typically use the URI fragment for navigation purposes. Changes to this fragment are solely handled by the client-side JavaScript code. There will be no GET-Request induced by the browser when the URI fragment is changed.
That's why the approach you described doesn't work for you. Using Page.open(...) will open a web page through a HTTP GET-Request resulting in a complete reload of your Vaadin application.
The solution for your problem is to solely handle all navigation (including state-dependent redirects) through the Page object's URI fragment handling methods (or through the [Navigator][1] component). Redirecting in Vaadin can be achieved by programmatically setting the URI fragment with Page#setUriFragment() or Navigator#navigateTo() and having your URI handling code (or Navigator) take care of the rest. Only then it is assured that your users stay on the same page even when they are redirected to a login form or to some other place after logging in.

I would like to add to Roland's answer and share how I solved this.
My UI:
#Override
protected void init(VaadinRequest request) {
setSizeFull();
setContent(masterView);
getPage().addUriFragmentChangedListener(event -> present(event.getUriFragment()));
present(getPage().getUriFragment());
}
The masterView is just a CustomComponent that has a content section. When the menu is clicked, I simply setContent to the masterView's content section. Swapping out the middle, basically.
present method:
private void present(String fragment) {
masterView.setContent(getComponentFromFragment(fragment));
}
Finally:
private Component getComponentFromFragment(String fragment) {
if (fragment.equals(someOtherView.NAME))
return someOtherView;
return null; // null clears it out as in the welcome page
}
The important part is the present in the init. When the UI renders for the first time and fires the init, it goes ahead and grabs whatever the URI fragment is in the browser and presents that as well.
Works great.

Maybe this can work:
UI.getCurrent().getPage().executeJavaScript("window.location.href = 'http://google.com'");

Related

Wicket implement flash redirection

I would like to perform something like a flash redirection (not sure if it is really called flash redirection).
After a certain action like delete device, I am redirecting to the device list page.
Now, for the redirect URL... I am appending &sdr=true and it works.
The problem is... that parameter (&sdr=true) stays there even after just refreshing the page.
If I remember it correctly, when I do flash refresh... the parameter stays there but will disappear on refresh... or just good for one refresh only.
Below is my method for redirection:
public static void redirect(String redirectUrl) {
throw new RedirectToUrlException(redirectUrl);
}
now, how do I implement the flash redirection in wicket? I am using wicket 6 version.
Or... I would like the parameter &sdr=true be good only for 1 request. When the page is refreshed or reloaded... it should be gone.
Thanks :)
Sorry if this question is very easy, I am really new to wicket
May be there is another solution for your problem.
Wicket could be stateful, i.e. it can keep state between the pages navigation. So you can do:
setResponsePage(new SomePage(someState));
this way there is no need to pass anything in the url and SomePage's constructor can decide what to do with the passed state.
If you prefer to add request parameter in the url then you may use
PageParameters params = new PageParameters();
params.put("sdr", "true");
setResponsePage(SomePage.class, params);
In SomePage's constructor you will need to remove the sdr parameter from the passed PageParameters so that it is not rendered in all urls inside the page, e.g. in links, form action, etc.
But if you want the parameter to disappear in a page refresh/reload then you will need to make another redirect:
public SomePage(PageParameters params) {
super(params);
StringValue srdValue = params.get("srd");
if (!srdValue.isNull()) {
params.remove("srd");
// do something custom
throw new RestartResponseException(this);
// or throw new RestartResponseException(getPageClass(), params);
}
}

FlowRouter Reload Doesn't Route

I'm using FlowRouter. If I start on the homepage everything works well. I can work through the routes (change the pages) without problem. However, if I hit refresh in the browser, I get a series of errors. My url looks like this:
/story/586d536e34821281735b53a4
The ID is being returned in console under the following method:
Tracker.nonreactive(function(){
I think the subscription is being completed, so I'm a little confused as to why reloading a url is different than loading from the home page.
What am I not understanding here?
Reloading a url will make a HTTP request to server to get all the application source. Whereas navigating to a route from another one does not make any HTTP requests to get the application source because they are already available (they were loaded from the previous route), in this case the router will just get the appropriate content and render on the page. This is normal behaviour for Meteor apps and all other single-page apps
The error you encounter is because your data is not yet available on client, to fix it you could simple use a placeholder if the value is undefined.

How to integrate Google Identity Toolkit with a single webpage app (e.g. GWT)

I need to integrate Google's identitytoolkit (Google's identitytoolkit) with my Google webtoolkit (GWT) application.
However rendering the gitkit signInButton or widget is already not straightforward because the way to do it is linked to "window.onload". And I need to render the widget at a later moment.
I managed to do it (see below), but I am not happy with this and I wonder if someone else found a better way of integration.
private native void showGitKitWidget() /*-{
$wnd.google.identitytoolkit.signInButton(
'#gitkitDivId', // accepts any CSS selector
{
widgetUrl: "//127.0.0.1:8888/gitkit/signin.html",
signOutUrl: "/gitkit/signout",
popupMode: true
}
);
var evt = $doc.createEvent('Event');
evt.initEvent('load', false, false);
$wnd.dispatchEvent(evt);
}-*/;
Update
Actually using the popupMode parameter for the signInButton makes a seamless integration even closer. This lets the widget popup in a browser window and leaving the GWT window unchanged. Then in the widget instead of redirecting to the successUrl I use the JS callback to trigger an AJAX call instead.
var config = {
idps: ["googleplus"],
signInSuccessUrl: '//127.0.0.1:8888/gwt/servlet/gitkit/signedin',
callbacks: {
signInSuccess: function(tokenString, accountInfo,
opt_signInSuccessUrl) {
/* !!! Tell GWT parent window that we are ready...
I believe using a cookie for which the parent is
regularly looking is the way to go, because it
will work in mobile browsers too.
*/
return false; // prevents redirect to signInSuccessUrl
}
}
Update Finally the GWT parent window will wait for the result cookie and if found make the AJAX call to the signInSuccessUrl. It will also have to render the signInButton again, which will then show the signed in user.
So the only ugly workaround is how the signInButton is rendered using the onload method call.
It would be very helpful if there would be a way to render the signInButton dynamically when needed, for instance if there were a "$wnd.google.identitytoolkit.update()" method. This could be called any time for the first time and should also be able to handle signin-status change!
In conclusion, I have answered my own question, which might be helpful to others, but also I would still like to ask if there would be a better way, which I missed.
As you've noted, the Identity Toolkit widget currently needs to be triggered by page load. Single-page applications (like those built with GWT) should place the widget on a separate page. Then you can redirect the user there - or render via popup, as you've noted - to sign in the user in.
If rendering the sign-in button is a problem, there is documentation on how to load the widget directly.

URL fragment lost as part of SAML token authentication; workaround / standard pattern?

Several web application authentication protocols (like WS-Federation and the SAML protocol, i.e., so-called 'passive' protocols, and apparently also ASP.NET Forms authentication, see this StackOverflow question, and AppEngine, see this GWT bug comment) lose the original 'URL fragment', i.e. the part after the #-sign.
What happens is roughly the following: in a clean browser (so no cached info/cookies/login information) I open URL (1) http://example.com/myapp/somepage?some=parameter#somewhere. This makes the browser request (2) http://example.com/myapp/somepage?some=parameter, the server redirects me to my identity provider (including URL (2) in the authentication request), and ultimately I'm redirected back to where I came from, which is URL (2): that is the only URL that the server knows about. But I wanted to go to URL (1), and the URL fragment ('anchor') has been lost along the way, actually in the first step already.
This seems to be a fundamental limitation of these protocols, since the server never sees the URL fragment at all.
I know that it according to specifications that the browser requests (2) from the server, when I navigate to (1), leading to this fragment-losing limitation on the SAML protocol, WS-Federation, etc. My question is: how do I work around this limitation?
The obvious workaround is to avoid URL fragments, as suggested in this answer. However, for our specific web application that is not nice, since we use bookmarkable URL fragments in our single-page GWT application, to make sure that a navigation within our application does not cause the page to reload.
My question: What other workarounds or standard patterns are there for this situation?
(I'm specifically interested in a GWT + SAML protocol solution.)
You basically have two options:
avoid using location.hash (use HTML5's pushState instead, at least on browsers that support it; and/or propose a way to generate permalinks within your app – Google Groups does that)
do the redirection using JavaScript. I.e. instead of sending a redirect from the server, send an empty HTML page with some script that takes the full URL (with the hash) and does the redirection using location.assign() or location.replace(). With a bit of luck (depending on the servers), you'll be redirected to that full URL after authentication.
You can of course do both: if the link is a deep-link into the app, then do the redirect (i.e. assume there's no hash), otherwise send a page with JS to make sure you don't lose any state present in the hash.
And finally the obvious third solution, far from ideal: don't do anything, and try to educate users that when they needed to (re)authenticate then they should re-paste the URL or re-click the link or re-click the bookmark.
According to RFC 1738 anchor tags are not sent by the client to the server, when requesting for a resource.
Anchor tags are used to identify a location within a resource and not a different resource on the server. In order to identify the location in the resource, the client needs to fetch the complete resource from the server, and this process need not involve transfer of information about the fragment (as it does not mean anything to the server).
If you do wish to send the fragment character (#) to the server, then you'll need to encode it in the query string, or the client(browser) will simply ignore that section of the URL when it sends the request to the server.
EDIT:
I don't know any real solution but to work around this issue you need to save your full return URL (with anchor tags) somewhere on the client side, because server don't know anything about anchors. For that you could use SessionStorage (http://www.w3schools.com/html/html5_webstorage.asp) to temporary store ReturnUrl until login process is completed. Please note that it won't be supported on older browsers (like <= IE7).
In that case workaround would look something like this:
<script>
if(typeof(sessionStorage) == 'undefined')
{
sessionStorage = {
getItem: function(){},
setItem: function(){}
};
}
window.onload = function ()
{
var key = 'ReturnUrl';
//try to get last returnUrl with anchors
var returnUrl = sessionStorage.getItem(key);
//if we got something, do the navigation
if(returnUrl !== undefined && returnUrl !== document.URL)
{
//clean it up
sessionStorage.setItem(key, null);
//navigate to last URL
window.location = returnUrl;
}
else
{
//store url
sessionStorage.setItem(key, document.URL);
}
}
</script>
PS. Bear with me if there are some syntax errors because I wrote it down from top of my head and didn't try it.

Redirecting to second page in GWT doesn't load GWT components in second page

i am using GWT app engine to deploy my application in local host.
i want to redirect to second page when user completed his registration & clicked "submit" button, the browser has to redirect to automatically to his Profile page with his registration details.
i used fallowing code to redirect to second page from first page;
String url = GWT.getHostPageBaseURL()+"/UserViewProfile.html";
Window.Location.replace(url);
in my case the first page is URL is like:
http://127.0.0.1:8888/UserRegistration.html?gwt.codesvr=127.0.0.1:9997
when i submitted on "Submit" button it is edirecting to URL like:
http://127.0.0.1:8888/UserViewProfile.html
In second page(UserViewProfile.html) i developed simple HTML content & simple Textbox widget to check it's functionality. But i am seeing HTML content only but not "Textbox".
To see text box i has to type URL like:
http://127.0.0.1:8888/UserViewProfile.html?gwt.codesvr=127.0.0.1:9997
how i can access last part "?gwt.codesvr=127.0.0.1:9997" at end of my URL pattern automatically? if i add it manually, at the time of hosting it may leads to problem. please if any body give solution, that would be great.
I do not understand the use case. Anyway I guess you need to conditionally check if you are in DevMode or ProdMode, and add the gwt.codesvr=127.0.0.1:9997 query string accordingly. Something like:
String url = GWT.getHostPageBaseURL()+ "/UserViewProfile.html";
if (GWT.isProdMode()) {
Window.Location.replace(url);
} else {
Window.Location.replace(url + "?gwt.codesvr=127.0.0.1:9997");
}
The gwt.codesvr=127.0.0.1:9997 query string parameter is used by GWT to (simplifying) bootstrap your app in the so called Development Mode, instead of the Production Mode (the actual compiled version of your application). Without this check, if you are in DevMode, you end up requesting the UserViewProfile.html that looks for the compiled version of your app (that does not show anything, if you've never compiled it, or if you have simply recently clean the project).
Do also note that URL rewriting (by not simply changing the # fragment identifier), means application reloading.