Quick question here.
I'm creating a 3-step form for a user - all AJAX (and using Devise). The user is created on the first step, and updated on the second two steps.
Now, the issue is that if a user hits the back button in their browser to go back to the first step, the Devise automatically changes the form action to update. But, the my update action renders partials that should only be rendered in steps 2 and 3 via Ajax.
How can I make it so that the user is logged out when hitting the back button so that the first form is always a new_user form?
One solution is to disable back button in browser at all.
You can use a modal to implement the three steps. If you are using Ajax, use it at full.
By this, there is no "back" button on the browser. But you can still have "back" button on your modal window, in this case the back option is totally in your control.
Add
For usability you should allow users to update their info at any time, instead of forcing them to complete all right after signed up.
I don't know what your next two steps are. But you can
Setup the update method to render the next two steps if an user has not finished them, or render other info if finished.
Show a notice if an user is signed in but has not finished the two steps.
By these you should be able to ensure whatever the user do on their browser, he can see what he need to do next. These should be applicable to either Ajax or no Ajax.
Related
I have a 3 step report which loads by clicking a link with the remote: :true option, so it reloads a part of the page instead of refreshing the whole page. I also provide the user with breadcrumbs, so he/she can easily navigate between the steps. However, most users use the browser back button, which of course reloads the whole page. What is the "Rails way" of dealing with this? If the browser back button is clicked the user should see the previous step in the report.
If you need to control the history the user sees, but aren't doing full page reloads on form submit, you should be manipulating the history state via Javascript's history.pushState and friends.
Assuming the responds to the submitted form is some sort of evaluated Javascript, simply include the history state manipulations there.
I am having trouble with a page redirect issue in a small multi-step form process within a Rails application. Here's the rundown,
1.) There are 3 pages to this form with a, "save" and "next", button at the bottom of each page.
2.) If a user has filled out new information on the page, and attempts to click the next button, a warning modal popups and prompts the user to save their changes, or discard. This is where my issue is occurring.
3.) Instead of directing the user to the next page as they intended after pressing the modal save button, it instead just refreshes the same page the user is currently on.
I've tried everything, but honestly am not very experienced with Rails. I have made a collection on codepen for you to see all of the files.
Rails Files
Quick breakdown of the three files you will see.
1.) The saveModal is the popup that prompts for save or discard.
2.) Skills is just one of the 3 pages in the form. Any important info for you here would be at the top and bottom of the document I assume.
3.) The controller code where I think the redirect is happening is also there.
I am new to mvc application and i am using MVC 5 version.The scenario that i face now is like if i click browser back button on staying inside any webpage inside my application then login page should be shown instead of showing any cached page.
I added below code in global.asax to clear the cache.So after some time if cache is cleared and back button is clicked then expired page will be shown.
protected void Application_BeginRequest(){
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
Response.Cache.SetNoStore();
}
My intention is to show the Login action method at any point of time if browser back button is clicked with in the aplication.Please help me out guys..
According to me this should never be done.
The back button on browser is a client / user action and it has a specific behaviour. You should not try to change something like that.
But its all up to you if you want to do something that would be really bad according to user persceptive.
What you can do is use the unload event in JavaScript or jquery. This will not just let you know when back button is pressed but when anytime the page is navigated away.
I had used this when dealing with data entry form to confirm navigation away after user has entered data without saving.
The unload event is sent to the window element when the user navigates away from the page. This could mean one of many things. The user could have clicked on a link to leave the page, or typed in a new URL in the address bar. The forward and back buttons will trigger the event. Closing the browser window will cause the event to be triggered. Even a page reload will first create an unload event.
http://api.jquery.com/unload/
$( window ).unload(function() {
return "Handler for .unload() called.";
});
I think now you would be thinking of distinguishing what causes the unload event. But that is not possible, at least not in a cross browser way and without any hacks. You can refer this link for more details about it - Is there a way in javascript to detect if the unload event is caused via a refresh, the back button, or closing the browser?
update (copied from another SO answer):
Since you are doing this for logout-purposes you should probably use a timestamp variable at the server that gets updated with every request (or use a ajax-ping), and logout the user if it hasn't been seen for a specified time.
Suppose I have a Rails controller method, which is executed when the user submits a form. Now, the user submits the form, and while the method is running (and hasn't rendered the next page to the user), the user hits "Refresh". What is going to happen? Will the method stop running and restart, or will there be another thread to run the method once more?
I had to find the answer out for this myself, here is what I found (using Network tab on chrome inspector)
The browser sends the following requests:
GET /profile/123/edit (user brings up edit form)
PUT /profile/123 (user submits form)
The users hits refresh, which causes:
GET /profile/123/edit
In other words, it doesn't re-submit the form, it re-brings up the edit form.
Now... if instead of hitting refresh they hit submit a second time, that will send a second
PUT /profile/123
which will call your controller method a second time.
If that is a problem, you may need to add some logic to ignore or otherwise handle subsequent submits (simple state machine?). Remember the days when e-commerce sites had a message like "Do not hit submit twice" after you bought something... they didn't have that logic :)
I think this must be a common scenario-- but I can't seem to find a solution.
JQueryMobile site with authentication functionality:
Link on all pages takes user to dynamically loaded authentication page
All pages have back button functionality
A bad username and password causes an ajax form submission
Clicking the back button in this scenario takes you back to the authentication page (which makes sense because that's where you came from-- but if I input a bad password five times, I have to click on the back button five times before I get back to where I came from)
I guess what I want is to have the ajax form submission for logging in taken out of the "hash" history.
One way to solve this would be by keeping track of the failed attempts numberOfAttempts++. Then using history.go(-numberOfAttempts); when the back button is clicked.