I am wondering do I need to support the feature to refresh user form (share the link for it) while editing a user?
The scenario:
1. Admin clicks on edit user;
2. Filled User form loads on URL my-domain.com/user/edit/3;
3. Admin refresh the page;
4. The form loads again with fields filled;
Do I need to support this feature (Admin refresh the page and user data is still there)? Is this an unnecessarily extra?
Example scenario if I do not support this feature:
1. Admin clicks on edit user;
2. Filled User form loads on URL my-domain.com/user/edit;
3. Admin refreshes the page;
4. Admin being redirected back to users list;
I am using React and the question more specific would look like this:
Do the form component need to receive the user in props OR the user form have to load the user from the server itself by URL parameter (userId)?
I would say it's not neccesary.
Do I need to support this feature (Admin refresh the page and user data is still there)? Is this an unnecessarily extra?
Generally when I refresh the page its because I dont want to erase every field.. or the form doesnt have 'reset' button.
Related
basically I need some help and I have no idea how to progress or come up with a solution with this issue. This is a similar issue to when you logout of an Laravel app, and press the back button, it will display the information from the cache.
The problem I am getting is, if 2 users share a same computer. At one point the first user gets page 1 cached (after a form submit they get redirected to page 1). Now, I logout and login using the 2nd user. I go to page 1 then to view the form that was submitted but I then press the back button on the browser. This then leads to page 1 BUT with account 1 on page 1 instead of being account 2 on page 1.
I understand I can remove cache from all pages from my app but the app is currently quite large and relies on the cache in order to load page 1 otherwise I get a out of memory error. I also don't think I can make page 1 efficient enough to load without cache.
Is the only other solution is to have a back button inside the app on every page and disable browsers back button?
I also thought about using an intermediate page between the submit and page1 (therefore in theory would not cache page 1) but this would need to be done throughout the app on any form submit. Is this a possible solution?
Does anyone else have any other solution to this problem? I have the back button currently disabled but I realise it is an inconvenience for users.
Given that you have record of the session data inside a table in the database I think a solution could be, to have something like this inside a Controller
<?php
public function login(Request $request) {
//Process the $request data
$user = //Get user with a model function
if ( $user ) {
Auth::login($user);
}
}
public function logout() {
Auth::logout();
return redirect('/');
}
?>
In this case your User table should have fields with the user session data. If you like to use HTTP sessions then add Session::flush();to the logout controller function.
My goal is to make a modal window popup if a user clicks on a link to a page (or POSTs a form) for which he is unauthorized, as it is a better user experience than redirecting to a generic error page.
What I did is implement
protected override void HandleUnauthorizedRequest(AuthorizationContext filterContext)
{
// ...
}
so that if the request is a non-AJAX request then it redirects to the same page (gives the illusion of staying on the same page) and appends the query string with "forbiddenRedirect=true" and then JavaScript opens the error modal. I'm trying to think of a better way than using the query string. From what I can tell, there's no way for JavaScript to access response headers, only the URL. That's why I went with the query string solution. But maybe in MVC there's some way I can redirect and pass some sort of token that the base controller can recognize and then add something to the view bag like ViewBag.IsRedirectFromUnauthorizedAction = true.
Any suggestions?
The user should never get to a page where they can post data without being authenticated and authorised!
If your users can get to forms where they can post information (lets go with a User Profile Page), they should be authenticated before they can even get there. So for example, you would lead the user to a Log in page before you allow them to access the Edit Profile page. Once they have authenticated themselves and you have checked they are authorised to perform a POST on a particular page, then you present them with the form.
But what if their session times out?
In the event that the user authenticates and gets to that page, then their session times out, you should redirect them back to the Log in page where they are prompted for their credentials again and deny their post request. In an ideal scenario, you should have an AJAX function running in the background every 30 seconds or so. If they are idle for a set period of time (lets say 5 minutes) then you can assume they have closed the browser or left their PC unattended. At this point, either ask the user (via modal window) if they'd like to stay logged in or be logged out in 30 seconds. If they click the Stay logged in button, leave them be. If they don't answer, you can log them out and automatically redirect them back to the Login page.
I've coded some custom navigation buttons into the project I'm working on, via javascript - they essentially copy the browser button functionality (brief wasn't initially clear on why separate buttons were required, but they asked for them):
function goBack() { window.history.back(); }
function goForward() { window.history.forward(); }
However, as the functionality is the same as the browser back button, the website asks if I want to resubmit POST data if I go back to a page with said POST data, which is undesirable. Ideally, to fit with the current site setup (all POSTs submit to the originating page, which checks for POST data and performs the relevant submissions to the database), I want to clear the POST data so there is no request to resubmit.
I'm not familiar with the Post/Redirect/Get (PRG) that people might recommend, and it doesn't seem to cover the concept of continually pressing "back"; if you submit a form, you post to a page which handles the post action, then redirects to a GET page - but the redirect is still in the history, meaning if you go back, surely you would hit the redirect page and just be sent "forward"? Plus, PRG seems mostly centred on page refreshing, which is not what I'm looking for at the moment.
The concept of PRG also seems to be due to the browser back button not allowing for additional code to control POST data, so coders have to make the best of what they can access.
With my relative freedom of having a custom back button which could allow for manipulation of POST/session/cookie data, I'd consider there should be some method of calling a global session variable or cookie on back button press, which then gets picked up on the previous page load to unset the POST data and the global session variable/cookie, but my attempts to implement something like this have not succeeded - they've been simple single-line setcookie('back', true) or set($_SESSION['back']=true) PHP snippets within goBack(), with PHP earlier in the page:
<?php if (isset([either set cookie or set session variable]) {
unset([either set cookie or set session variable]); // also tried changing 'true' to 'false' here
unset($_POST);
}?>
Is this kind of behaviour possible and I'm just looking at this from the wrong angle, or is the only way to do a successful back action while suppressing POST to re-engineer the site to use PRG, which will be comparatively significant legwork? Is there some other point in a page load/POST submit that would allow for clearing the POST data, to allow for the back button functionality I'm looking for?
EDIT
I, as an example, navigate to site.com/stuff/edit/[an ID], to edit an item of stuff. The first time I visit, there is no POST data, so the PHP check of isset($_POST) returns false and the page is simply rendered with a form which is populated by a GET.
I amend in the form and press submit. The submit sends the POST data to the target page; this is STILL site.com/stuff/edit/[an ID]! However, because there is now POST data, the PHP picks this up, validates it on the page (you'll see why later) and performs backend model and controller functions to update the item to the database serving the site.
Depending on whether the update was successful, the page then renders the form again, with the information which is retrieved from a GET, which pulls the information from the server (amended or otherwise) and either a success or fail message.
If I want to add a new item, I navigate to site.com/stuff/new; this navigates to the same page as site.com/stuff/edit, but PHP code determines the masking URL and renders different aspects of the code to look like a different page with a different POST action - it also notes there is no ID passed in.
I add an item, and the POST redirects back to the same page; this time, though, there is no Id from the server, meaning the code behind picks up the fact it is a new entry, and performs an insert. It then either displays a success message with a link to view/edit the new item, or a failure message with a prepopulated form to reduce retyping the new item into the form.
I hope this has helped show how this page works; its not necessarily how I would have written the site, but I've inherited the work from an ongoing situation and work with others who code in this way, so I need to be consistent or make unobtrusive changes rather than radical redesigns of in-use code.
I think this should do the job:
function goBack() {
var referrer = document.referrer;
if(referrer != '') {
window.location = referrer;
} else {
window.history.back();
}
}
I'm working on a website where the user fills out a form and submits it with a button that sends a POST. I would like the user to submit the POST and be redirected in the same action. Currently I have a javascript redirect (with window.location) implemented but I wish the page was condensed better. Is there an easy way for the same element to send a POST and subsequently send a GET to a different address? If it wasn't obvious I'm new to web development so apologies if my terminology is incorrect.
Just set the action attribute of the form to the URL you want to process the form.
You can't have a "submit to one URL and redirect to another" in one action.
Your options are:
Redirect to the second URL from the first one
Use AJAX to post the the first URL and in JavaScript redirect to the second
I need to do the following:
I have a textbox, which appears in every page of the site, that allows to subscribe to a newsletter. This I've done already and the user is redirected to previous view after subscription.
I'd like to add a javascript alert to the page the user is returned to, something like "Thanks for subscribing". How can this be done?
Thanks in advance.
EDIT: Propably it's not clear from the post tags. I'm using ASP.NET MVC 2 Preview 1
If you are doing a HTTP redirect, then the page you will render needs to be passed some information so that it knows to include the javascript to open the alert box (adding an optional element to the page might be a nicer way to do this).
That information needs to be stored either in a browser cookie, or in a session store (which is keyed from a browser cookie). You can remove this once you've rendered your message, so that it is only shown the first time you visit that page after the redirect.