This one is really racking my brain:
I need to post non-sensitive data to a third party payment gateway. I want to use the built in cakephp form validation which is working fine.
What i am doing is submitting the form to a local action which calidates the data and outputs any errors if there are any. Where i am stuck is trying to re-submit that post data to a remote url if there are no validation errors. The problem is that the browser must be redirected to the external url with the post data... I think i lost it about here i know this is probably not possible...
My plan B is just using javascript for form validation and posting directly to the external url.. I looked into using curl but I need the browser to redirect/open the extrernal url. I s there a way to get curl to redirect the browser when posting to a url?
There are several routes you can go down for this, depending on your abilities and other business-related decisions.
My recommendation would be for you to use the AJAX validation methods to validate your data. Your server would then be used for validation (and you could store relevant details like invoice number, customer information, etc.) Once it validates you can have the page submit the form data to the 3rd party site. Note that it's likely you will run into some security related issues depending on how your security certificates (for SSL) are setup.
Another choice (one that I would consider a bit more secure) would be for your site to accept the data. If it doesn't validate, request fixes from the client (pretty basic Cake stuff here). If it does validate, you can then use libcurl to send the data to your 3rd party processor, forming each variable properly in the POST data in your request.
You're not going to be able to redirect the client with a POST payload. Either of the two options above would help you get the job done. I would personally use the second method, for the following reasons: 1) easier auditing / debugging (it's already in your server environment, etc.) 2) more secure - you can lock down your server better than client systems, 3) it seems cleaner to me (the client doesn't see connections going all over the place, etc.) and 4) you can modify and track requests as they pass through your system (respond appropriately to clients when the processor reports an error, etc.)
All in all, this is a doable thing. Does your 3rd party offer an API? You might look into that as well.
If an extra step is okay in your application flow, you can easily do it like this, no Javascript needed:
User fills in form as usual.
Form is submitted to Cake action as usual and validated.
If validation is successful, you display an intermediate page with all the values in hidden or read-only form elements.
Submit sends the hidden form to the external site.
To the user you can present that intermediate page à la "Please confirm your data one last time, click 'Back' to change data or hit 'Submit' to submit it to an external site."
The only option I know of is using JavaScript.
If you wanted to just send data, there would be a number of options. But redirecting the user is a different story.
Your best bet might be to rethink why you want to send the user to a different site.
It's a little complicated to use CURL to redirect, but it's possible, and not terribly hard. It's even easier if you know specifically what URL to redirect to, or if you can build that redirect url. Here is an example curl call:
/usr/bin/curl -D "/tmp/0001" -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)" -H "Cookie: key=value; key2=value2;" -H "Content-length: 89" -d "this=is&the=post&data=true" http://url.com/application.php
Let's walk through the command:
the -D will store any return headers into the file "/tmp/0001". From here you can parse out any redirects that you need to find. Just run something like grep Location /tmp/0001 to get the line with the location redirect header. That is if the app itself redirects. This is also where you parse out any cookies.
the -H is the header that you are sending to the server. You can post a Cookie: header if the page requires cookies. You may also need to generate the content length based on the data you post.
the -d is the data that you are posting to the application This is for an actual "POST".
Once you do your initial post and get that working, you simply call /usr/bin/curl again with the second url. Simply build the headers the way it should look for that second page, along with any cookies it sends you, and it should post as if it were a browser.
The results of the curl command will be the actual page, that you can log to some database for verification purposes.
I hope this helps.
Related
I have a simple web form that feeds into Infusionsoft. Not my call. I had been submitting it fine with curl to run an AJAX routine, to eliminate then going to Infusionsoft's domain and a thank you page - instead just displaying a thank you/error msg based on the return. All good so far. The problem I've run into is with the affiliate cookies. Apparently each time I set up an affiliate it generates them a url to my sign up form that has their affiliate data in it and sets a cookie in the url (http://www.example.com?p=XXX&w=XXX).
I'm getting that stripped out with my curl routine. How do I keep a 'url cookie' enabled when submitting through curl? I apologize if my terminology is incorrect, this is beyond the scope of what I usually do and would appreciate any correction.
I know it's a curl_setopt but don't understand them enough to make a qualified decision. I basically just need it to keep alive the session that was started with the url. I know this post is lacking, but unfortunately so is my understanding.
The affiliate cookie is tied to the infusionsoft.com domain and you can't access that unless your script is on the Infusionsoft domain. The only other way to do this is to use some hacked version of the instructions on this page - http://kb.infusionsoft.com/index.php?/article/AA-00878/0/How-can-I-track-affiliate-activity-if-I-capture-leads-or-process-orders-through-the-Infusionsoft-API.html
Best,
Jordan
You can do it with modern browsers, because you can make a CORS AJAX request to the hosted version of the web form on InfusionSoft's site. You have to mimic all of the form fields and names, including the hidden ones. So you will need to submit the form to their hosted WebForm version and use Firebug or Chrome's dev tools to watch the HTTP request. Then you will have to submit your form, using the same form fields/names to wherever the action attribute of their hosted form is pointing via an AJAX request.
I have implemented this successfully using AJAX, it just doesn't work on IE 7, 8, and 9 because of CORS AJAX security issues. My workaround for those browsers is to use cURL as a proxy to submit the form. The only downside for those special case browsers is that they don't receive the cookie that shows which URLs they've visited in their web profile in InfusionSoft.
I'm afraid that you're all gonna need to reach over and put on your "this-is-a-dumb-question" hat, but I can't find a legitimate answer online.
I can find all sorts of crazy info on sending cURL requests to a site and have them send back a response and processing that response.
My question is I want to BE the site that receives this cURL requests. How do you set up a page to process those types of requests? How does it work?
I ask because in the near future I will need to integrate this into a project I'm working on. Other sites will send me info that I'll need to process and store in a database. Ideally, I'll probably need something to handle HTTP POST requests and obviously I'll need to know what security measures I'll need to take as well. It also would be nice to know how to fire back a response to the person who's making the request. I also will need to know how to configure user authentication....such as with:
curl_setopt($request, CURLOPT_USERPWD, "Username:Password");
I feel silly asking, but I can't figure out the right search keywords to use to look up this kind of info. Even just a link to a relevant site would be appreciated.
Thanks in advance. You all rock.
All that cURL does is act as a user agent. Any user agent can access a php page.
So to be the site that receives cURL requests (or to have such a page) all you really need to do is create a normal php page that would work as if a user were using it. Whoever is using cURL to make the request will have to know what data you are expecting on your end.
If you want to use CURLOPT_USERPWD for authentication, you have to set up apache (or whatever server you are using) to password protect that page. This can't be done in the php script directly. However, the php script can have it's own form of authentication either instead of or in addition to this authentication. There are millions of ways to do this (openssl for example, or just anticipating a static string depending on how secure you want to be).
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'm trying to submit data to SalesForce.com, but I'd like to do it through AJAX. Since there are restrictions to deter XSS, I'm having jQuery use AJAX to submit to a PHP page on my server and then having that page simply forward the formdata it's passed along to the proper URL.
If I submit the form with JS turned off, everything goes through fine. If I turn it on, Salesforce confirms receipt of the data (in debug mode), but it's not showing up in my queue, or anywhere really, in SF. SF spits back all of the fields it was passed, and it's spitting back every field that I have in my form, properly filled out.
Are there any differences between submitting something through this method (jQuery's $.ajax() to PHP cURL) and through the native HTML Submit button? Something that could be causing SF to register the data, but register it differently? I've tried adding CURLOPT_HEADER/CURLOPT_HTTPHEADER information
Well, the only thing that's different that you can't fake is the IP address of the request. Depending on how tough the protection is that salesforce is using, you may not be able to spoof from a separate IP address (it would detect and deny the request).
Everything else should be 100% fakeable (headers, etc). What I would suggest is that you get firebug or TamperData and look at the raw headers being sent to salesforce from your browser normally. Then replicate that exact request from PHP. If you need other information, you could detect it in JS and pass it to PHP (Cookie information, browser info, etc)...
$.ajax() transmits cookies from the client browser; and it also adds a "X-Requested-With: XMLHttpRequest" request header.
Maybe try adding the (external) IP address of the machine that is running the php code to the list of trusted networks in salesforce. Login to salesforce, and go to setup -> security controls -> network access, and add the IP there.
I ran into a similar problem and had to add the ip address of the server that was running the java app that connected to sf and this fixed the problem for me.
I don't know whether this is possible, I can't seem to find any other help guides so this may not be possible...
I have a checkout page which POSTs a load of variables forwards to a 3rd party payment processor (WorldPay).
I want to know if it is possible to put a PHP script of some sort inbetween the two pages for validation purposes.
EG if an item in the basket has sold out while they were filling out the form, it could catch the customer before money is taken. Or useful if they tamper with form data.
If I do this on my own site I could use sessions to pass the POST data forward but as it's an external website, I don't know how to send the data without making another HTML page with a hidden form & refresh for instance.
Is it possible to do this 'invisibly' - not actually showing a HTML page inbetween?
Yes you can do that by hooking into the onsubmit hook of the form and sending out an Ajax call like this (using jQuery):
$('#myform')[0].onsubmit = function() {
if (form_check_elements(this.elements)) { /* ««« eg JS validator here */
data = $('#myform').serialize();
$.post('/ajax_validator.php', data, function(data, textStatus) {
$('#myform')[0].submit(); /* ««« check the textStatus before here and
eventually do not submit (wrap it in
an if-clause) */
});
return false; /* make the form not post directly */
} else {
return false; /* do not post if JS validation fails */
}
};
We use this snippet to store form data in a session before posting to a 3rd party so we have it available when the 3rd party returns to our page.
Edit: Keep in mind that this will only work with JS enabled, but it is fallback-safe: The form still submits without JS support.
EDIT:
Ashley said:
Okay, i've taken a look at the cURL
manual and written this very simple
script to forward the POST values to
the 3rd party checkout. This just
displays the contents of the checkout
page though. The URL address shows the
script currently running rather than
forwarding to the 3rd party site. Also
all their relatively linked graphics
will not work. Can 'true' forwarding
be achieved using cURL?
The short answer - no.
With the way you described your payment process if you want to step in the middle of the offsite process to do things (customize html/messages, validate data, etc.) then you need to handle the entire process which cURL would allow you to do.
With cURL, you dont "forward" the request - you sort of "proxy" the request. So the fact that the browser URL never changes and that the relative graphics dont work is expected. With the use of cURL or something similar you would never let the user end user know that they are even touching an external page. you would be handling all the requests to that external server on your server and then simply displaying the response from the external server to your user OR parsing that response so that you can use the data from it in a customized way.
Essentially this means if secure.wp3.rbsworldpay.com/wcc/purchase is returning a form that requires futher interaction from the user you have to mimic this form on your server and display that instead. Then when the user submits your form you use cURL again to make a request to the external server - this time to post the next round of data submitted by the user. So for example lets say:
secure.wp3.rbsworldpay.com/wcc/purchase shows the cart
secure.wp3.rbsworldpay.com/wcc/confirm shows a final confirmation of the payment to be made
secure.wp3.rbsworldpay.com/wcc/success and secure.wp3.rbsworldpay.com/wcc/error show whether the transaction succeeded or failed respectively.
Then you are actuall going to need to make 2 requests externally as part of you transaction process which could be summarized like so:
User shops at your site and adds items to cart
User clicks on checkout and you validate the cart/user data
If the data from #2 was valid you package up the data and post to secure.wp3.rbsworldpay.com/wcc/purchase via cURL
If the cURL response from #3 was successful you build your own confirm page using data from the cURL response and display it to the user.
The user submits the confirmation of the purchase to your server.
You package up the data submitted to your server in #5 and post it to secure.wp3.rbsworldpay.com/wcc/confirm via cURL.
If the cURL response from #6 was successful then you parse it for the expected "error" or "success" message returned from external server and display them or your own custom error messages.
Rinse and repeat in case of error ;-)
Generally speaking most payment processors have an option of processing that supports this basic process often returning easy to parse data as XML, JSON, or Plain Text instead of HTML. You might want to look in to this. A lot of times they will often have libraries built for various programming languages to help ease the integration process.
Yep it sure is... i normally use the curl extension to do stuff like this, or an http client class that utilizes curl. You might want to make it a tad easier on yourself and use one of these class libraries - for example Zend_Http_Client. It supports not only curl but also sockets and proxies.
Yes, you can. What you are looking for is the CURL function:
http://php.net/manual/en/book.curl.php
Also see:
http://php.dzone.com/news/execute-http-post-using-php-cu
I rather like the HTTP_Request2 package from PEAR, which basically wraps cURL and/or sockets in some simple objects. POSTing works great. You can use that to bounce the POST request to your validation-checker, then on to the payment processor.
I would suggest you to go like this:
Before directing a user to the form, you check (through SQL queries) whether the item in the basket has sold out. If it has been sold, redirect the user to some other page saying that this item has been sold out otherwise let him go to the form for new purchase.