what is the link between backbutton and continueToOriginalDestination(). method.
how to keep url saved for continueToOriginalDestination() method while clcking browsers back button.
continueToOriginalDestination() is used when a request was (temporarily) redirected to an intercepting page, for example a login page. When a user requests a secured page but is not yet authenticated, the security framework that hooks into wicket (auth-roles, shiro, swarm/wasp) will present the user with a login page, and store the original URL. When the user has authenticated, you can call continueToOriginalDestination and Wicket will process the original request, displaying the requested secured page.
Not only security frameworks can use this, you can do it yourself by throwing a RestartResponseAtInterceptPage exception.
The back button has nothing to do with this, nor does it have any affect on the processing of the original destination page. Wicket keeps storing the original destination until a new one is set, or until continueToOriginalDestination has been called.
continueToOriginalDestination returns true when there was a page to go to, and false when the user landed on the intercept page directly (e.g. guessing the login page URL or clicking on a link pointing to the login page).
Related
I am working on web app in OutSystems 10.0. In the application, if I log out, it logs off. But when I click the browser back Button, it redirects to the Previous page (which should be displayed only after login). Any suggestions?
You probably need to have roles on the pages, if the pages have the role anonymous anyone can open it.
You're probably accessing the website via http and not https, so when you press back on the browser it will show you a cached version of the previous page.
Because it's the cached version, the session and roles are not checked.
As a recommendation, force the https protocol.
Following the link provided by #Abdulhakeem, they recommend the following:
Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
Add a bit of Javascript to the page ready event to:
Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else
I recommend downloading the .oml provided in the post and reviewing how they actually implemented it.
if you can change to https, you can also in every action that is on the page that do changes on the database. check if you have permissions or you are logged. that way if the person tries to do back and do some action you can redirect it somewhere.
I have a JSF 2.0 application that is used for creating accounts using Self Registration. On the first page, there are fields like name, email, uid etc. Typical to any registration, we show the confirmation page, (other custom pages as well in between) and the final success page. Each page is rendered in JSF using the faces-redirect=true so there are 3-4 pages(facelets) in the entire process. In this application, I use a SessionScoped backing bean to show the middle pages/confirmation page/final page etc. After the registration is complete, I clear the SessionScope bean from session and invalidate the session.
The problem is:
The confirmation page/middle page etc. show the User details that the User entered from the first page(using the EL from the backing bean: #sessionBean.firstName etc.). So, if the User enters this URL in the browser directly (host/appName/confirmationPage.xhtml), the page loads with blank values (as the User did not go to the first page directly). Also, after the registration is complete, if the User clicks on the back button blank values show up (no-cache is explicitly set in the filter class, so cache is not used here which is the correct behavior)
How do I force the User to go to the first page if the firstName etc. is not present. i.e. when the User lands up on a page, make sure that User landed on this page only through the first page in this session?
Should a filter class be used? Or should a prerenderview event be used to check for blank values and redirect them to the first page? There is no "User Login" here as there is no authentication. I believe this is a common use-case and I would like to know if there is any best practice in JSF
We're hosting a PHP facebook canvas application (http://apps.facebook.com/myapp). One of the pages (http://apps.facebook.com/myapp/foobar) requires authentication from facebook so we can access some information about the user. This is achieved by using the PHP-SDK's $facebook->getLoginUrl() method to generate the url for authentication and works as expected.
We have since added the app to as a Tab (iFrame) to our Page (http://www.facebook.com/MyPage?sk=app_nnnnn). Now when we try to authenticate the user they are redirected to the app's url (http://apps.facebook.com/myapp/foobar) rather than having the /foobar page load in the Tab's iFrame as expected.
Is it possible to set the auth so that it doesn't bounce to the app's url but stays within the Tab using the PHP-SDK? If so, what is the workflow I should follow to achieve this?
I would simply add code to http://apps.facebook.com/myapp/foobar to check for authentication, and if it is, echo:
<script type="text/javascript">
top.location.href = 'http://www.facebook.com/MyPage?sk=whatever';
</script>
That should break out of the iframe and redirect you to where you want to go.
The way I have achieved this is to do the following:
On the /myapp/foobar page I check to see whether the user has been authenticated. If they haven't I set a session value and use the PHP-SDK's $facebook->getLoginUrl() to generate the auth url and send a response back containing just the javascript to redirect window.top.
Once they've authenticated they're redirected back to the main page. When this page loads it checks for the session value and, if set, removes it and issues a redirect header to /myapp/foobar.
It's a little convoluted but seems to be quite a stable solution.
I have a bunch of pages which should only be accessible when the user is logged in. So that the URLs make sense, and also so that the user may bookmark them, I have made them bookmarkable URLs in Wicket.
Now the problem occurs, that if the user comes to view these pages, but is not yet logged in. The constuctor which takes a PageParameters on my page is called.
My approach is going to be:
For all pages which should only be available logged in, but which are bookmarkable, put an if statement in this constructor to test if the user is logged in or not.
If the user is not logged in:
Store (a) this.class (b) the PageParameters in a special place in the session
setReponsePage to be my login page
In the login page, if the login is successful, check to see if these special attributes in the session are set, and if so, then setResponsePage to be the class/parameters of the desired bookmarkable URL
Is this approach correct? It seems to be a bit of extra/manual work (although not too much!), but Wicket provides a lot of useful stuff "out of the box": so my question is: is this necessary or is there some Wicket facility I'm not aware of which I can take advantage of?
You should use a IAuthorizationStrategy to protect your pages. See for example wicket-auth-roles for a simplistic roles based library.
When Wicket tries to render the page that is mapped to the bookmarked URL of the user it will notice the user is not yet logged in (since the session has no user assigned to it), store the current requested URL, redirect to the login page and wait until the user correctly signs in. In the onSubmit of your login form you then call
if(!continueToOriginalDestination()) {
setResponsePage(SomeReasonableDefaultPageLikeYourHomePage.class);
}
See for an example the Authentication example in the Wicket Examples project (online demo here)
continueToOriginalDestination will instruct Wicket to render the original URL that the user requested, if one is stored, and otherwise return false.
I want to do history token rewriting. Don't know its possible or not.
e.g. If my application URL is http://localhost:8080/myapp/#login which contain 'login' as history token. Is it possible to rewrite the URL like http://localhost:8080/myapp/user/login.
Or is it possible to remove '#' from history token?
The # token has special meaning in an URL. The browser interprets everything before the # token as the page to load, and everything after the # as additional information for on the page. This means if something is changed in the URL after the # token, the webpage is not reloaded, but it does create a browser history item. GWT uses this to create new history items, while not reloading the page.
If you would rewrite the URL from #login to /user/login you would instruct the browser to reload the page, which means the whole GWT page is reloaded and all state information is reset. This is probably not what you want.
So the short answer is, although it's technically possible, it will change the behavior from a one page website to a multi-page website that reloads every time the history changes, and that's probably not something you want.