I have a form that users post to but now this form is going to handled on an external website to my application.
I have tried using Location and curl and can not manage to get any of these to function correctly. My goal is to take the $_POST from my form and redirect the user to the external website posting the values.
Is this possible without using an html form and javascript to submit it?
Sending the Location header like that will generate a HTTP 302 response to tell the browser to go elsewhere, however, this will cause the browser to retry with a GET request.
If you want to redirect with the original method and parameters, you need to send code 307 or 308, depending on whether the redirect should be considered temporary or permanent. You can do this in PHP using http_response_code, e.g.
http_response_code(308);
header("Location: www.google.com");
Related
I want to hide the url of a specific page to prevent users accessing it directly.
I have a form which users have to complete before being redirected to www.******.com/xyz.php.
When they have completed the form and been redirected, is it possible for the url to be displayed as www.******.com?
look forward to any advice!
Whilst it may not be best practice you can serve one set of html for an Http Get action and another for the Http Post action. Your get action can return the form and the response to the post action could return your second page.
There are a number of reasons that this is a bad idea, these include
Http Post is meant to cause a state change, not guard access to a
page
It is easily defeated with any sort of proxy or rest client
Navigation in the browser may behave unexpectedly
The user would have to fill in the form for each visit.
It is far better to come up with an alternative solution like generating a temporary access token or setting a cookie to say that they have completed the form.
The best solution is perhaps up for debate, but a simple is solution is to have two .php pages Let's call them index.php and form.php. Your web server is configured to serve up index.php when a GET request is made to www.example.com. (The exact method to do this will depend on your server software).
index.php checks for a cookie and redirects to form.php if the cookie is not set. See this question/answer for more details
form.php responds to a GET request by serving the html for the form and to a POST request by setting the cookie and redirecting back to index.php.
I am supposed to capture data from a form and send the data to a url on a different server.For eg:-I have a form on a page at the url http://www.form.com/register.php.
I capture all the data from this form and for some reason need this data to be processed on a page on another server at http://www.thereceivingpage.com/process.php.
As of now I am using headers to redirect with the parameters in the query string something like this:-Header(Location:http://www.thereceivingpage.com/process.php?name=alice&address=a1&address2=a2) but I need to send a larger amount of data which wont happen as GET request. Can anyone suggest a better way where in I can post data rather than the data in the query string ...thanks
Use cURL. If you have to redirect to the site, it gets a bit trickier but you can still do it. You can get the cookie and redirect information back from the site and then do a GET redirect using header.
Can you not update the action to simply post directly to that form? Otherwise, you might want to look into something like curl: http://ca.php.net/manual/en/function.curl-exec.php
You'll pretty much re-use the header redirect syntax with the parameters but instead you'll tell it to be a post.
redirect to a page on a different server and post parameters to it
thanks to internet standards, that's impossible.
if it's third-party site, let user to interact with it directly. do not interfere between them, it smells
If you want to develop secure applications then you should be aware that http://www.thereceivingpage.com/process.php is vulnerable to Cross-site Request Forgery (CSRF), meaning that anyone, from any site, can post form data to process.php.
process.php should be checking for a token (which www.thereceivingpage.com transmitted to the user as part of the form) and should be rejecting form submissions that don't contain the token to prevent submissions coming from anywhere but www.thereceivingpage.com and thus protecting your users from being manipulated into making requests they didn't want to.
In addition to your concern about the size of the GET requests you cause the client to make when redirecting, it's also not a good practice to turn POST requests into GET requests.
The best solution is to completely rethink the notion of delivering a form from one site to be submitted to a different site.
You can manually set headers and send request or you can use curl
see this
http://www.askapache.com/htaccess/sending-post-form-data-with-php-curl.html
I got help with solving a problem in this thead: Redirect with POST data. Now that I decided that the whole site and even this function must work when JS is disabled I need to get some suggestions for a non JS solution as well.
The need is:
User fills in a form and click on a button.
When clicked part of the form is saved in the db and part is posted to another server (payment-server). The user should only need to click once.
If you want to make the browser to re-send the data of a HTTP Post request to another URI, the HTTP/1.1 protocol offers the 307 (temporary redirect) response status code to signal such to the HTTP-client (Browser):
header('HTTP/1.0 307 Temporary Redirect',$replace=true,307);
header('Location: some_new_url_here');
Read the specs carefully and see the notes on the 302 status as well.
It's much more useful to handle the payment over an API on server-side instead of risking a user being irritated by additional messages displayed by the browser where the user must actually decide whether or not the additional redirect is to be performed.
Use CURL extension to post request to payment server when processing your user's request on server-side.
If your user must be redirected to some external web site, than save needed data first and then redirect him using header() function. Keep in mind that in this case you wouldn't be able to use POST method for making request to remote payment server.
A redirection with HTTP Location would have your user end on another site. I suggest you trigger an HTTP-request from your server using curl or streams.
The reason they initially suggested AJAX is for user experience, and is not a requirement for a form to be able to post. You will need to either present the user with a separate step to choose a form or have the same page reload or load another page.
Some pseudocode for example:
<?php
if (!isset($_POST['form_type']) {
display_form_selection();
} else {
switch ($_GET['form_type']) {
case 'credit_card': display_form('credit_card');
exit;
case 'cash': display_form('cash');
exit;
default: display_form_selection();
die()
}
}
Your form_selection() routine should draw a form which has a select, checkbox, radio button or whatever that will POST a string or integer (for the switch) back to the script you are running from.
When the page reloads it will call the correct display_form() based on the value it passed to itself. These functions will set up the form for whatever you want to post to the gateway.
I have read elsewhere on this site that using for your form action is not a good idea, and you should rather manually type your script name in.
I'm a bit confused. How do I POST data to a URL and then redirect the user's browser to that location - all in one operation?
I see
header('Location: page.php?' . http_build_query($_POST));
but that is GET, not POST and ppl think thats really bad practice - PHP open another webpage with POST data (why?)
My kludgy workflow involves setting up a form and then submitting it via javascript - anything has to be better than that...
I think I can do a set of header() stmts but this action happens for the user way after the page has been geenrated, so i dont think that would work
You cannot redirect POST requests. As simple as that. Any redirect will always turn into a GET request.
If you want to receive POST data, then send that data to another page, you have two choices:
if both pages are on the same server, use sessions to save the data server-side, don't make the client carry it over
if the destination is on another server and you need to send the client there together with the data, set up another intermediate form like you are
Use AJAX to save the data before you leave the page. Use the answer you get back to fire a redirection to the new url right within the current page. Don't be affraid of Javascript and ajax. Try this light AJAX library: http://www.openjs.com/scripts/jx/
I have a PHP script setup using Jquery $.post which would return a response or do an action within the targeted .php file within $.post.
Eg. My page has a form where you type in your Name. Once you hit the submit form button, $.post is called and sends the entered Name field value into "mywebsite.xyz/folder/ajaxscript.php"
If a user was to visit "mywebsite.xyz/folder/ajaxscript.php" directly and somehow POST the data to the script, the script would return a response / do an action, based on the submitted POST data.
The problem is, I don't want others to be able to periodically "call" an action or request a response from my website without using the website directly. Theoretically, right now you could determine what Name values my website allows without even visiting it, or you could call an action without going through the website, by simply visiting "mywebsite.xyz/folder/ajaxscript.php"
So, what measures can I take to prevent this from happening? So far my idea is to ensure that it is a $_POST and not a $_GET - so they cannot manually enter it into the browser, but they could still post data to the script...
Another measure is to apply a session key that expires, and is only valid for X amount of visits until they revisit the website. ~ Or, just have a daily "code" that changes and they'd need to grab this code from the website each day to keep their direct access to the script working (eg. I pass the daily "code" into each post request. I then check that code matches in the ajax php script.)
However, even with these meaures, they will STILL have access to the scripts so long as they know how to POST the data, and also get the new code each day. Also, having a daily code requirement will cause issues when visiting the site at midnight (12:00am) as the code will change and the script will break for someone who is on the website trying to call the script, with the invalid code being passed still.
I have attempted using .htaccess however using:
order allow,deny
deny from all
Prevents legitimate access, and I'd have to add an exception so the website's IP is allowed to access it.. which is a hassle to update I think. Although, if it's the only legitimate solution I guess I'll have to.
If I need to be more clear please let me know.
The problem you describe is similar to Cross-Site Request Forgery (CSRF or XSRF). To protect you against this you could put a cookie into the browser and have the cookie value sent in the post form too (by hidden field or just add it to $.post). On server side check both those fields, if they match the request probably came from your site.
However the problem you describe will be quite hard to protect against. Since you could easily make a script (or use Crul) to forge all kinds of requests and send to your server. I don't know how to "only allow a browser and nothing else".
Use the Session variable as you say plus...
As MyGGAN said use a value set in a cookie (CVAL1) before rendering the submit forms. If this cookie is available (JS Code Check will verify) then submit.
On the server side:
If this cookie value exists and the session variable exist then the HTTP Request came from your website.
Note: If the script (form) is to presented under another domain DO NOT allow the cookie value (CVAL1) to be set.
Do not allow HTTP Requests on the Server Side Scripts if extra Http Headers Are not available (like x-requested-with: jquery). JQuery sends a request with an X-* header to the server.
Read more on Croos-Site Request Forgery as MyGGAN suggests.
I am not really sure REMOTE_ADDR would work. Isnt that supposed to be the end users IP addr?
Firstly, you could make use of
$_SERVER['HTTP_REFERER'], though not always trust-able.
The only bet that a valid post came from your page would be use a captcha.
try to use HTTP_SEC
// SECURITER
if ($_SERVER[HTTP_SEC_FETCH_SITE] != "same-origin")
die();
if ($_SERVER[HTTP_SEC_FETCH_MODE] != "cors")
die();
if ($_SERVER[HTTP_SEC_FETCH_DEST] != "empty")
die();