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.
Related
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.
Page A is the parent. From page A, the user clicks on a link and a new page B opens. I do not own page B. Then there, there is some kind of registration form for the user to complete. I need to know in page A that the form on B is submitted correctly when it happens (inject JS?).
I will handle the JS to determine if the form is completed or not. What I'm asking if it is possible what I am looking for, to send back the info to page. I would do this using an iframe, all within the same page but I am getting mixed content errors as page B is in http (I need my page A to be in https).
Normally this is not possible, but sometimes forms have some kind of callback, for instance forms from payment providers. They allow you to send your customer to their payment page, and they redirect them back to a callback page after the payment is done. Hopefully PageB supports such a thing, otherwise, you're in trouble.
One possible solution, if the form isn't very complex, and doesn't have much scripting, and doesn't require logon or other session or cookie related stuff, you might use file_get_contents or curl to get the form, modify it a little to post the changes to another script of yours, and then, from the server, post the form data to originating server. That way, you capture the entire form and everything the user submits is submitted through your server, giving you all the information you need.
Of course this is not easily possible with every form, so you'll have to try if it works for this one.
I have a control in a large ASP.NET application. The control uses AJAX to communicate with the server, and stores a very large amount of state locally. All of the pages consuming this control make excessive use of ASP.NET post backs.
I need to persist the control's state across post backs, but I need the state to be wiped out when the user navigates away from the page, either by browsing to another location or performing a post back that redirects. I cannot send this state to the server and echo it back.
Currently, I'm using sessionStorage, but it doesn't satisfy the requirement that the state be wiped out if the user navigates away from the page.
As a caveat, I have zero control over the consumers of the control.
How can I accomplish this? Is this even possible?
I don't generally recommend this, but the following may actually be the best option for you since you are working within strict confines of the standard WebForms paradigm.
You can implement IScriptControl on your control and add AJAX functionality using Microsoft Ajax, or alternatively create an extender that extends your control with AJAX capabilities.
You'll want to use this in conjunction with an UpdatePanel so the control can still post back as usual and the ViewState mechanism remains intact, but the postback becomes an asynchronous communication with the server. Any control data, ViewState or otherwise, is local to the control/page, meeting your requirement that the data is cleared when you navigate away.
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).
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.