I've got an html from on a public access tablet.
Is there a way to reliably prevent a user from going back in history to view past form submissions?
I'm looking to solve it either server-side or using javascript, or combination of the two.
I tried javascript code that prevent the back action, but it only works on the immediate back, press and hold to view further back options still allows going back.
The form is set to remember values when submission fails, but should not be able to get them after a successful submit.
is this perhaps better to do using sessions and handle using php?
There are many ways to prevent re-submission of forms through clicking the back button:
One way is to set all the form fields to be empty, this can be done on load of the page.
You could use sessions to ensure that the user has already submitted the form.
Cookies and/or local storage can be used as well.
However, querying the database to check for duplicates or resubmissions, or setting the form fields to empty strings on the client side would be a better option, as a user could delete cookies and clear local storage.
Related
Here is my problem...
We have a very large Form with many inputs and check-boxes, the problem happen when the user's pc disconnects he then need to restart the form.
After doing many Google searches I've found a few solution but i have no exp using any of the following and would like to know which solution is better used.
Save a session with post variables so that when user returns his data would be saved. (problem is with session destroyed when browser leaves page.)
Save the post variable to a temporary table, and if host name of user is there to populate the form to continue where he left off. (Probably the simplest way)
Session Storage and Local Storage, Both of these seemed like a good alternative but haven't seen any examples or any docs on how this can be used to populate forms.(No Exp with this.)
I'm thinking of using the second option and just wiping that table after 1 hour but would like to know which is better in terms of what is more widely used for this solution.
Thanks
you can send the data with the onBlur on the textfields with ajax post to a php file which writes them into the session or a coockie or a database.
Session ends when the Browser(not the tab) has been closed. Coockie must be aktivated by the user. So i think the temporary table is the best solution for you.
A site I am working on requires user information to be collected from a form when the user presses the submit button. The site will then take the information and plug it into a more robust form on a different page, so the user does not have to retype the information twice.
Is this possible using javascript?
Any help appreciated.
Once the user leaves the current page, the JavaScript on the original page is no longer running, They will load up the other page and run that page's JavaScript.
Do you have ownership of both pages?
If so, then you can leverage the form GET to pass information across pages, so the next page will have a Query string, and JavaScript can parse that.
Another way to move data from one page to another is to use Cookies. So it really depends on how much data you want to move around.
But I highly recommend that you leverage the server-side technology to handle the form GET or POST and carry information across pages.
This completely depends on the OTHER site. You can have a form with the same field names and post it to the same URL the other site's form uses.
BUT - if that site checks to see where the original post came from, it may block you out.
I have a web application which is used by lots of non-technical users. I have found that several of these users are saving the login page of the application to their desktops (which also saves the associated CSS and JS files). Then, to start using the application, they double click on that desktop icon which shows the local copy using the file:// protocol.
This can cause problems later on, e.g. if I change the login form, or the URL it posts to, etc. Also, certain javascript utilities, e.g. PIE.htc don't work using the file:// protocol.
Obviously what they should be doing is saving a browser bookmark/favorite, I'm looking for a way of detecting and warning those users without confusing the rest. I have been using some javascript to warn these users:
if (top.location.protocol == 'file:') {
alert('This application is not designed to be accessed from a desktop copy...')
}
But this will only warn users that have saved the desktop copy since I have added this piece of javascript.
Has anyone else had this problem and come up with clever solutions that they'd like to share?
Thanks
Update:
In the end I decided to do this by setting a cookie with a nonce value upon login page request, and storing the same value as a hidden field in the form. Then, in the form submit handler, check that the two are the same and show an error message if not. One could store the nonce in a session instead of a cookie, but I don't want to create unnecessary sessions.
If the user has saved the login page locally, they will likely have different nonce values in the saved form compared to the cookie (if they have a cookie at all).
Normally one wouldn't add CSRF protection (that's sort of what this is) to a login form, but it fulfills my requirements. I read about this technique on The Register, http://www.theregister.co.uk/2009/10/02/google_web_attack_protection/, Google implemented similar protection for their login forms, to protect against forging of login requests, http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests.
I think your best bet is going to be educating the users to use bookmarks instead of saving physical files.
Other than that, there's probably a way to create a shortcut to your URL instead, perhaps during logon?
Maybe cookies? If site is running with file:\\ there probably are not any cookies within request. (Of course, now you should add some cookie (session data) on your login page.
Also, read about CSRF http://en.wikipedia.org/wiki/Cross-site_request_forgery and preventing method.
You could probably check the http referrer on the server side and warn users not coming from your hosted login form.
Edit:
Actually, a vaguely similar question has been asked before and got a good explanation why referrer is not an ideal solution and also provides an alternative solution: How to check if a request if coming from the same server or different server?
Why, don't you, instead of the alert, put a redirect to your page?
window.location = 'http://www.yourdomain.com'
Or you can also force a reload with window.location.reload();
Instead of message you may redirect your user to the real page which has login form, or show the help box that will explain that user should save page in such way.
You could set a session variable that is set as a hidden variable in the form. If that is not there, you redirect to your login form.
I have a page that is generated from a bunch of grails templates being rendered, with javascript widgets and stuff, that specify parameters for a search engine we are developing. The problem is, if someone clicks on a person returned in the search results and it takes them to another page, and then they hit the browser back button, the search parameters and dynamically created widgets and previous search results are all gone.
I dont really want to have to programmatically re-build the page based on the search parameters (which I can save as a session variable), and I would then have to re-run the search query again to get the results back. is there a way to save a page just as it was created?
Thanks
Popup a javascript window with information about that person instead of taking them to another page. In the worst case set the target of the person link to _new and that will force open a new browser window/tab.
At some place the search parameters have to be saved. Either on server or client side. On the server side you only have the options session or flash scope.
On the client side you could store those values in a cookie. This needs some bits of javascript.
However theoretically the browser will keep manually changed form field-values out of the box. He is identifying the form fields by its name/id. It should not be necessary to do any programmatically things, except if you are loading some parts of the page via AJAX. Maybe you can doublecheck, that the input fields have static name/id pairs or you have some meta/cache/html settings, which prohibit such mechanism (double check, that your form does not have autocomplete="off" setting set. This will prevent the browser to refill your form fields.
Grails itself does not offer things like you need out-of-the-box (and I do not know if other frameworks have - maybe except for Seam, which has a concept of conversation scope; but even this feature will not work out-of-the-box if the user uses the browser back button). The easiest way is to make your search page some kind of cacheable (for the browser, by settings HTTP-headers or meta tags), so that the browser is not trying to reload the page from the server again, if the user presses the browser back button. And double check the autocomplete="off" setting.
I went to test my page on another browser. On google chrome i can fill out a form, hit back and forward and still have the data there. Now i need to refresh the page so certain data is correct (such as session id if the cookie expires or user logs out before submitting). I refresh and lose all data. Is there some option i can set so all data is kept?
What framework are you using? For example, ASP.Net WebForms would handle this via ViewState (yuck), ASP.Net MVC would require you to do this manually etc.
You essentially need to persist your data somewhere while the page reloads, and then re-populate the controls.
You would have to send the values to the server while they are typed in, and then repopulate the form fields on refresh.
Yes, the only secure way to do this is to use a serverside script to store the form temporarly. Since browsers handles back/forward diffrently your page won't be x-browser compatible if you don't use the server. If the user hits the back button you are kind of lost already since no post is done, unless you post the form with some javascript magic before the new page is refreshed.