Laravel app, account swapping when pressing back on browser - javascript

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.

Related

Support refresh on user edit form

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.

Redirect using post and get the succes of the redirect

Say, I have a simple form on my website having three fields : name, password and email.
I have to get these information from the users, and keep in my database.
Then redirect to another website and send all these information using post.
I also have to know whether the user was successfully redirected to that site(HTTP STATUS 200).
Here's how I'm doing it:
For Point 1, I'm simply submitting the form.
After the data has been successfully saved in my database, I'm rendering the following form with hidden fields. This gets submitted and user gets redirected to anotherwebsite.com
<form id="form_id" action="https://www.anotherwebsite.com/form" method="POST">
<input type ="hidden" name ="name" value ="$name">
<input type ="hidden" name ="password" value ="$password">
<input type ="hidden" name ="email" value ="$email">
</form>
<script> document.getElementById('form_id').submit(); </script>
Problems:
I don't think my strategy to achieve point 1 and 2 is correct. I need a better solution. Submitting the form, then rendering a page with hidden fields and submitting it again to redirect to another site just doesn't feel right.
I have no clue to achieve the 3rd point.
Based on your question you might try this approach:
create a form with name, password, email fields in a file ( HTML ).
Submit the form to server.
On the server side get the data (including the form attribute in a variable) and save it to database.
then redirect to the given website ( using the variable you've stored in step 3 ).
You can easily know the status ( 202 or any error) using any of server side scripting language.
If you are sending the user to another website, the only way to know that the user was successfully redirected is for that website to notify you in some manner. Once the user leaves your page (and that's what a redirect is - it tells the browser "leave this URI and go to this URI instead"), the scripts on that page stop running, so they can't collect any further information.
If you just need to know that the information was submitted successfully, your script could POST the data in the background, wait for a 200 response, then redirect after the information has been submitted. But that may not meet your requirements, since you still won't know if the redirect succeeded.
Another possibility which does allow you to know whether the page on the other site loaded correctly would be to open it in a new browser window/tab instead of redirecting. This is the only way to keep your page active (and, thus, your scripts able to run) while loading another page. However, it introduces other issues, like what to do with the original page. (Leave it open in the background (likely to confuse the user) or close itself after seeing that the new URI has loaded (could cause undesirable visual artifacts as one window/tab opens and then the original one closes; destroys browser history)?)
If at all possible, having the final destination site notify you when the transaction completes is almost certainly the best way to go.
To achieve point 3 you need to use cookies if you are actually trying to implement a login-cum-membersarea system. Othewise, you simple need a redirect inside a condition statement.
my $cgi = CGI->new;
if (condition) { print $cgi->redirect('https://www.examplesite.com/file.html') }
for a general way of doing point 1-2, you can look at the tutorial here:
http://practicalperl5.blogspot.com/

How to append to form "Thanks for the email!" after submit button is pressed?

I'm building a contact form for my website and I would like users to enter their information, click submit, have the information process with php and to just have a message display on the bottom of the form. Originally, I was redirecting to another page and the form was working properly, but now I just want to append a small message and can't get it to work.
This is what I have currently in my contactengine.php file for it to process all the variables and send the email.
if ($success){
THIS IS WHAT I DID BEFORE THAT WORKED BUT HAS TO REDIRECT
// print "<meta http-equiv=\"refresh\" content=\"0;URL=index_thanks.html\">"; //
//BELOW IS WHAT I WANT TO OCCUR
<script type="text/javascript">
$("#contact-area").append("Thanks for your message!")
</script>
}
You don't need JavaScript for this. JavaScript is great, but it should only be used where necessary, since it can add some brittleness to the user experience.
Here's a possible design approach:
Set up a POST form
Process the form, set a session variable to thank the user, and redirect to the form again. This switches the browser from POST to GET mode†, and is usually as simple as this:
header('Location: http://yourdomain.com/form.php');
exit();
Render the form as usual. If a session variable is set to thank the user, render the thank you message, and unset the session variable‡
I wouldn't use a <meta /> refresh here - it needs to load more data to work, and is more fiddly to implement.
† The POST-redirect approach is a common design pattern in web development. There are plenty of resources about this on the web, if you are unfamiliar with it. It fixes problems associated with rendering web content inside a POST method, particularly in relation to page refreshing and using the back/forward buttons.
‡ These temporary session variables are sometimes known as flash variables. They exist from one HTTP operation to the next, and are erased at the end of the second operation.
You cannot put JavaScript inside of your PHP code. However, I will give you an explanation of what you need to do.
On the client side, bind an event for the click, then
$('form button').click(function() {
$.post('file.php', {'object': 'property'}, function(success) {
if(success) {
$("#contact-area").append("Thanks for your message!")
}
});
});
On the server side, you will process this:
//file.php
$sentByAJAX = $_POST['object'];
return true;

Remove POST data when using custom javascript back button

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();
}
}

Restrict confirm message on page reload with f5

In my JSP page I am using post method while submitting the page.
So once I go from Page 1 to page 2. In Page 2, If I press F5 I am getting alert as
"To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier."
I knew this question is a bit sarcastic but please give me an Idea.
I can't change my method from POST to GET because I need to send large amount of data.
Thanks in advance...
Edited:
In my Page1.JSP I call onClick function in that function I call action as "/page2servlet.do".
Now, In Java side I use Spring Framework. With MVC Object I return to page2.jsp.
So where do the response.sendRedirect Fit.
Do a redirect to Page 2 after POST. You will not receive the prompt anymore.
After doing POST save all the info you will need to session and send an instant redirect to other page with GET. Then on that other page get all the info you need from session.
However, after the session expires user wont be able to press Refresh. Also, it will break multi-windowing. User won't be able to do 2 distinct submits in separate windows as they will share same session object.
<?php
session_start();
if(!isset($_SESSION['disablethispage'])){
$_SESSION['disablethispage'] = true;
// serving the page first time
}else{
// visited before or page was refreshed
}
?>
Here is a version that replaces the next page:
http://plungjan.name/testredirect.html ->
redirect.php ->
thanks.html
and here is redirect.php
<meta http-equiv="refresh" content="3; url=http://plungjan.name/test/thanks.html">
<script>
location.replace("http://plungjan.name/test/thanks.html");
</script>
redirecting..
.

Categories