Make browser cache form data when submitting with AJAX - javascript

I have a web application with a number of forms throughout. Everything is submitted with AJAX rather than doing an actual form submit. The problem I've run into is that I want the browser to still cache the values the user enters in the forms for auto-completion when filling out the same forms later. I'm sure there's something that could be hacked up with localstorage, but I would prefer to use the browser's native caching of form data if possible. Any ideas?

If I'm not mistaking, it completely depends on the settings of the user's browser and cannot be changed. The only way to do it is to use the localStorage (or server-side storage for older browsers).

Related

disable viewing past content/history in html

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.

What is the pros and cons of using ajax to submit form?

I have been using a lot of AJAX to submit forms such as register user, log in user form and so on.. Now, I want to know is it safe to use AJAX for such sensitive information such as userID and password forms ? What is the pro and cons of using AJAX when submitting form ? (security wise and so on).. Thank you again for any kind explanation and enlightenment..
PROS:
AJAX definitely has the advantage over the User Experience and Convenience. AJAX allows you to do checks with the server without refreshing the page. For example, it allows you to check if the username has already been used or not without resetting the form. However, since the users information is processed in Javascript first, Cross Site Scripting attacks can easily grab data from your script. However, even without AJAX your Cross Site Scripting can still be used.
CONS:
However, since AJAX is fetches data asynchronously, it usually renders the browser back button completely useless. Also, people who don't understand "web tech" sometimes turn Javascript off due to their own paranoia, thus AJAX can no longer run. I also heard that content rendered through AJAX are not usually visible to search engines, but I'm no SEO prof.
It's the exact same as using a normal form there is 0 differences. The pro and cons are the same as a normal html form.
I think you can use SSL or TLS if you want better security but don't hold me to that :)

How to prevent users from accessing a web application from a locally saved Html login page?

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.

Save state of view of page in grails

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.

How do i make form data not disappear after hitting refresh?

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.

Categories