Send POST from php Zend-Framework site - php

I am currently working on a zend framework site using an ACL.
The ACL works and uses a DB for storing privaliges. What I have done so far is, on in a preDispatch I capture where the user wanted to go to, and if they need to login to get there the page displays the login form. I have also captured if a user has submitted a form and stored the data (location and form data). No problems so far.
The user submits the login form, and I then check if I have a location to send them onto, again no problems here, this works.
However I want to be able to submit the original form data now they are autherised - the only problem is, if I redirect them to the page, the call to:
$this->getRequest()->isPost()
fails as it isn't a post request.
I can forward the user to the page on sucessful login, and in the preDispatch set $_POST to the data originally captured, this works as the original POST still stands, this works but I do not think is the correct way to do this - specially the URL - obviously the page displayed is correct, the form has been submitted correctly, but the URL is of the login process.
Obviously I could change from using $this->getRequest()->isPost() but as there are large amounts which would need changing I was hoping not to have to do this.

The way it's done usually (seen this on many sites), would be to store the form data and requested action in session, then redirect the user to a login page. When login is authorized, you read the session for any pending action, reload the form and populate it with data from session (properly clearing any pending action from session afterwards). The user would just have to click Submit again.
The other way to do this would be to use HttpClient and submit the data as POST with it.

Related

Laravel persistent $errors and old() input data for next requests and clearing them

I have been working on a controller that makes modifications on existing data. The initially received response gives the client a view where client can fill a form and submit it as POST request. After the POST request is handled, client gets redirected to the same page where he/she filled the form.
The problem here is, form is not actually part of that view that is acquired with GET request. The form is being loaded with the help of a button and AJAX request to another route. This part is important: form is not part of the view, it is loaded with an AJAX request on that view.
So, what is the problem? The problem is, I'm currently providing invalid data to the form so I can check out the validation system is working correctly. I should to feed client back with proper error messages and load the form with old inputs that the client has provided. But when I try that, I get the old input and errors on the view, after submitting the form. That's great, but once I click that button to load the form into the page and open it, there's no old input or error data. That is probably because Laravel's old input data and errors bag is only available for the next request. When the controller redirects the client to the route that responses with the view, it receives the error and old input data but when it loads the form by making an AJAX request, they are already cleaned.
To overcome this problem, I have been resetting the old input and errors with the same values for the next request, like below:
#php
session()->flash('errors', $errors);
session()->flash('_old_input', request()->old());
#endphp
This solution was working good on the page that loads the creation but I also have the same mechanism for editing the added resource. Refreshing the old input and error data works for creating phase but doesn't work as well for editing. I have made sure I'm doing everything same for both actions, I checked it out but I couldn't find why there's such inconsistent behaviour. So I dediced to look up for another solution.
How do I make error data and old input data persistent? I will probably need to remove these session datas after the controller done its job or after showing the data to the user with the form view. How do I do that?

Process form only if sent by server

I have some pages in my web app which deal with the sent data from a form. I want to avoid the following situation:
An user creates (in the client side) a form with the same fields that my original form and sends it to the url which process the forms. Then, my process page receives the form sent by the user and processes it.
Is there any way to do that only forms sent via my web application get processed?
An easy way is to generate a random token, set that in a session variable when you generate the form and add is as a hidden field to the form.
When the form is sumbmitted, you can check the session variable against the form field value.
That ensures that a visitor would need to request the form first but of course they could still to that programmatically, get the token and add that to the form submission.
Are the users not authenticated?
You might want to research around CSRF. There are many articles detailing how to go about that, see below:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
http://blog.ircmaxell.com/2013/02/preventing-csrf-attacks.html

Multi-page form without registration using sessions

I am trying to allow the user to post data to my server as part of a multi-page form without requiring registration. This form post includes a file upload. I'd rather not use ajax for the whole form if I can help it.
This raises the issue of what happens if the user abandons the form mid-way through.
I am new to php but I was wondering if the following is sensible:
Page 1: On "submit", store infromation in session
Page 2: On "submit" store page one and page two data in database.
That way I can have multipage forms but the information is only loaded to my database when the user completes the second page.
Would something like this work?

PHP - return the same page with changes

I have html page where you can insert some information and then submit this form, which will change information in database. I do it normally, that submit button call php file in server.
But what I want, is that this php file will return to me the same html page of which I sent request, with modified changes. e.g: there will be "Database update successfully" text added etc.
How can I do it without AJAX ?
Thanks
In the PHP file, do a call to the header() function to redirect the user. For example:
header('Location: url.php');
To change the content of that page they are redirected to, you could pass something in the URL that your page will check for. For example:
header('Location: url.php?submitted=1');
There are other ways to implement this, but this seems the most straightforward to me. Note that you don't want to call header() until the end of your submission page.
Use POST/REDIRECT/GET
Excerpt:
The user submits the form
This is pretty straight forward. The user completes the form and submits it by pressing the submit button or enter on their keyboard.
We store the form data in a session
After processing the data we discover an error so we need to redisplay the form with an error message but we also want to populate
it with their data so they don't have to refill the entire form just
to fix potentially one little mistake. So we store their data in a
session ($_SESSION). Session variables carry over from page-to-page
for as long as the session is valid or until they are deleted. This is
an ideal place to put their information since redirecting will cause
their information to be immediately discarded by the server.
We redirect the user back to the same page using a 303 redirect
Once we have saved the user's information in their session we need to redirect them back to the same page. In order for this to work
properly we need to use a 303 redirect. This means we need to send a
303 header with our redirect. A 303 redirect will cause the browser to
reload the page without the initial HTTP POST request to be
resubmitted. This includes when the user uses the back or refresh
buttons.
We re-populate the form using the data stored in the session
When the page is sent to the user we re-populate it with their information we saved in their session.
Only by generating the whole page in CGI first, unless you go through some horribly convoluted method of getting value of one of the fields to be set to document.innerHTML or something like that in Javascript. But you'll go through hell to get the quoting issues resolved. Use AJAX, it was created for precisely this purpose and exactly to avoid the utter hell associated with what you need.
Alternatively: the "modified piece" of the page may be an iframe, and you can set the target attribute of the form, so that the PHP returns only the iframe content.

How to handle browser back button for dynamic content

I'm writing a PHP app which presents people with a form to fill out and submit.
Once the user submits the form, things change in the database and the form should become inaccessible to the user.
If, however, the user presses the back button after submitting the form, they can see it again. I have code in the back end to prevent a user from being able to re-submit an already submitted form, however ideally if the user presses the back button, they will get the same message as if they were to just navigate to it outright: A message is shown on the screen saying that this form has already been submitted and is now unavailable.
Aside from an AJAX call to the back-end to check if the form has already been submitted, and redirect the user to the "form submitted and now unavailable" message, is there any other (better?) way of handling this?
Since this will only be used internally on a SOE, I only need it to work on IE8+.
You can consider adding this information to session/cookie. Alternatively if you have authentication system, you can store this information in the database.
Probably the first option is easier and sufficient.
so basically before displaying the form you check if the cookie alreadySubmitted is 1. If yes - error message, otherwise - form. When you submit the form, just set this cookie to alreadySubmitted.
However be aware, that if someone deletes cookie, he will be able to trick your system.

Categories