In my web application, I'm providing a link, clicking on which goes to another page, shows some data,popups a page and goes back using javascript back() function.
It was working fine but it fails in certain cases. For example, this link appears after a form submission also. When the back() function is called here, the Webpage Expired message is shown because it was a POST operation.
How can I go back to the previous page using javascript in this situation?
Please provide your inputs...
You can't do anything about page expiration from JavaScript - that's how the browser opts to protect the user from re-submitting the form accidentally.
You could use the POST/Redirect/GET approach, depending on how your application works, to ensure users always land on a GET after submitting their form, so you always have a valid state to go back to.
To be honest, 99% of the time using the back() functionality in JavaScript is an indication something's wrong in the underlying approach. It's just too fraught with problems to be workable, as you're seeing here. You might get further if you start a new question to describe what you're trying to accomplish. There's a lot of really smart people around here who can all put their heads together and help you come up with something.
Can you explain why you need to navigate to the previous page using client-side script? I'm assuming it's because the user may be arriving at this page from various other pages and you want to direct them back to the page they came from. You could always store the user's previous page URL in a session or cache object and direct them back to that URL in server-side code. Or, if you know where they will always be coming from, direct them back to a static URL. I may be able to offer more assistance if you offer more details.
Related
I have a single webpage that uses an API to query backend for data, which is returned and plotted in a few figures. Backend is Node.js with Express.
The appearance of the figures is controlled through a set of JS functions that are loaded when the page initially loads.
After the user has been on the page for 30 seconds, I want to ask them to login or register by displaying a modal over the page.
If the login is successful, I'd like to close the modal and have new functionality available to the user, including changing the behavior of the original JS functions that were loaded when the user first arrived. But, I'd like to do this without reloading a new page with a separate set of JS functions.
I'm a relative newbie at this and have been having a hard time figuring out the right way to accomplish this.
I thought maybe there was a way to update the original JS function file by submitting an API get request and using the response to overwrite replace/overwrite the non-authenticated version. Then user would have access to new functionality without having reloaded the page.
But, I can't seem to find anything that would support this as the correct approach, or even whether this would be possible.
Really need help on which direction to go.
I'm new to web development and I'm trying to make small projects to better understand how javascript works and how interactive websites are made. So I wanted to make a simple website that would save links that you would enter using input/form submission. but what are the ways which I can use to store it on the server so when I open the page next time the website retrieves the saved information and displays it?
I know this question is pretty open, but I'm really lost in this part of web development because I'm seeing too many completely different things on the internet like PHP, ASP.net and what not. Can someone help me out?
It would be very thankful if someone can send me a link to a related tutorial or some similar resource, as well.
If you to do that, you will need a server side program with a Database.
Here is a tutorial for PHP, a popular language to do web pages http://www.w3schools.com/php/
When you submit your data in the form, That data will be sent to the file mentioned in the action attribute of the form. Now, each input element of your form will have a name attribute which you can use to refer as a key in your GET or POST super global array depending on the method attribute of your form tag.
I know it may sound confusing without example. But, This is explained at many links on the web. Try searching for form submission with post.
Decide on which technologies that you want to work with. I prefer you to use ajax with instead of just using javascript.
Link for flask tutorial http://www.fullstackpython.com/flask.html
Store the data in the client side is much simple I think. While storage in client, you can use localStorage sessionStorage and cookie.
localStorage you can storage whatever you want and it has no expiration time
sessionStorage the difference between localStorage is that it has a expiration time, A page session lasts for as long as the browser is open and survives over page reloads and restores
Cookie is much simple and can store limited value in string format
When a user lands on my page, say, www.somepage.com, I want to display some randomised content. But I want that content to be bookmarkable, so the URL should be changed on the client to something like 'www.somepage.com/?showparts=2,7,12', where the numbers can be different.
I do not want to do a redirect every time the user goes to 'www.somepage.com' so that it refers the user to 'www.somepage.com/?showparts=2,7,12', since that will require 2 round trips of communication with the server, making the site appear slow to the user.
So is there a way to make the user's browser show the URL as 'www.somepage.com/?showparts=1,4,6,30' in the one request and response when they navigate to 'www.somepage.com'?
I have read this thread: Is there a way to change the browser's address bar without refreshing the page?
But that thread is about changing the page after user interaction, so after the page has already been loaded on the client.
My question is about whether there is a response code or something to change the browser's URL in the first response sent from the server to the client when the client first navigates to the site.
I have read about history.js (https://github.com/browserstate/history.js), but I was wondering if there's a more simple solution in a response code or something. If the only solution is to use history.js, how should I do it? I was thinking that I could add a javascript call to the html page sent from the server as follows:
History.pushState(null, null, "?showparts=1,4,6,30");
Any pointers would be appreciated.
Thanks,
Keith
My understanding is that you could use the History api as you've illustrated here to solve the issue you describe. Have you tried it? What kind of problems are you having with it?
OK, so basically I've put together a very low security log in page (javascript username and passwords) which isn't a big deal cause there isn't really anything it's protecting, I just made a login page for the youth on my church website to view and study Sunday School material. What I'm wanting is to make it so you can't type in the direct html to your "profile" or bookmark it, I want them to have to use the javascript log in. For example, the script will direct bob to his "profile" at bob.html, but I want to only go to bob.html only if it comes from login.html, is there any way to do this without getting extremely complicated? I'm expecting there isn't but I thought I'd ask anyway.
If no server side programming is involved you will have to use a simple JavaScript redirection which is not even considered as a "low-level" security but as a "non-level" security :)
Anyway you can check the referrer with document.referrer and redirect to the main page when its not correct, remember that this is very easy to manipulate by the user.
More details on document.referrer can be found here http://www.w3schools.com/jsref/prop_doc_referrer.asp
if ((document.referrer).indexOf('login.html') > 0 && username=='someone' && password=='pass') {do stuff} else {user did not arrive from login.html or username is wrong or password is wrong}
If this is all from client-side javascript, then you can't do anything that's real security. I'm assuming you know that.
But, you can create a slight obstacle to direct access for the casual viewer by having the link from the login page set a very short expiration cookie (like 1-5 minutes), then go to the profile page and have the profile page have all the profile content hidden by default (via a CSS rule). Then, your javascript can check to see if the cookie is present upon loading and, if so, show the content.
If the viewer tries to go directly to the profile page, the cookie will not exist and the page content will not get shown by the javascript. Obviously, the content is still present in the page so any viewer with any knowledge of how web pages work could still see the content in other ways, but it wouldn't show by default in the browser.
Multiple schemes are possible, like the one presented above by jfriend00.
You can also use rolling URLs.
Say your profile page is at http://example.com/profile/foo. Change it to http://example.com/profile/foo?time=yyMMddhhmm where yyMMdd represents the current date, and hhmm represents the current server time. Then make sure that the server refuses to serve this page if the time doesn't match.
Easy to see what happens if someone bookmarks this link. Their bookmark will work for at most one minute.
Unfortunately, the link on the page also expires in one minute. You can solve this problem that updates the URL roughly every minute, but it is not as straightforward as it may look. You will need to take into account the fact that the time on the user's computer may be different from the server time.
Another way to do it is with a session cookie. Session cookies are good until the browser is closed. They expire automatically when you close it. This is a variant of jfriend00's original answer.
Hope this helps.
End users are often told not to hit the submit button twice, allowing the transaction to complete; and, there are different techniques used to address this situation.
Recently though, someone asked me, "what do you do to handle the situation of a user doing a page refresh after doing a submit", the implication being that this will cause a double submit or other problem.
Can you let me know if this is a real problem that needs to be handled ... what the situation is and how to best resolve it, if at all.
The best way to resolve this is using the Post/Redirect/Get pattern.
Yes, this is a real problem unless you handle on your side. In practice on most browsers when the user hits refresh the data is resubmitted and if you on the server side do not check for this it would result in you taking the same action twice (e.g. charging a credit card twice, duplicate forum post et.c.).
The way to handle this is to check whether the user has previously done a post. For example, if you are building a forum you would send a hidden variable with a unique ID with the post. As you parse the posted data you save this unique ID into your database. If you ever encounter a post with a unique ID that has already been saved you know that you are looking at a "refresh" on the client side and you simply disregard the post.
Hope this helps!
If your users are so inclined to do a page refresh, it sounds like you have a service taking way too long to respond. Disable the submit button on submit, and show some kind of loading indicator until the response comes back.
Alternatively, respond immediately on the server and queue the action for later. Linode, for example, queues server behavior, rather than running immediately on "request to resize partition". You can generalize this approach for other behavior, and even show things like progress indicators and the like with ajax.
Yes, it can be a problem (and actually is a problem in a lot of websites).
But I think this is more of a server side related question than Javascript.
Best practice is to use Post/Redirect/Get pattern (since you are asking specific about refresh after submit).
Yes it is a real problem but I believe this is typically handled by the browser. Chrome for instance will notify you on page refresh if there will be data posted to the server as a result, and give you the option of continuing or aborting.
EDIT:
Actually... come to think of it I did have to deal with this at work. What I ended up doing was creating a shadow box over the page untill the process was complete to
give visual feedback that the process was working and
Prevent any other user actions.
"what do you do to handle the situation of a user doing a page refresh after doing a submit"
You should redirect to the page after a form is succesfully submitted.
This would prevent that the user submits the data again and prevents that anoying alert of the browser saying the data will be submitted again.