I have a little issue with a application wich is specified the following:
I need to send to a credit card payment webservice some data by post, so the webservice will proccess the information and return a XML.
I thought I could do it with the $.post() jQuery Ajax method.
That's my code:
$.post("https://comercio.locaweb.com.br/comercio.comp", {
identificacao: dadosPagamento[0],
modulo: dadosPagamento[1],
operacao: dadosPagamento[2],
ambiente: dadosPagamento[3],
bin: dadosPagamento[4],
idioma: dadosPagamento[5],
valor: dadosPagamento[6],
pedido: dadosPagamento[7],
descricao: dadosPagamento[8],
bandeira: dadosPagamento[9],
forma_pagamento: dadosPagamento[10],
parcelas: dadosPagamento[11],
autorizar: dadosPagamento[12],
capturar: dadosPagamento[13]
},
function(data) {
alert(data);
window.open('../negocio/index.php?mod=cliente&acao=gambs&xml=' + encodeURI(data));
$('#resultadoFinal').html(data);
}
);
The alert(data) I'm using just to test the response, and the problem is:
I send it to local test file (# window.open('../negocio/...') ), and then the response is working ok, otherwise in the webservice (https://comercio.locaweb.com.br...) there's no response, and the XML I'm waiting for doesn't even exist.
Does anybody know what's happening?
Or if I'm doing it the wrong way, could someone tell me a better way to get the XML sending data by Post?
Thank you.
Vinicius,
It looks like you are trying to use ajax to interact with a web service running on another domain? Browsers will not allow this due to the fact that they follow the Same Origin Policy when making ajax requests.
There are a number of methods to get around this limitation. One of which would be to host a proxy on your PHP site which performs the web request for you. Then your code can make the request the page that you host (which is allowed under the Same Origin Policy) but you are still able to call this service you require. There is a more detailed description of this limitation available on this page which even includes sample PHP code for this proxy page.
There is also a JavaScript library called easyXDM (which is mentioned in the Wikipedia article above). This library will determine the best method to use to perform this cross-site communication based on the user's browser. More information on this project is available here. I'm not sure how widely used easyXDM is in the wild, but I see that it does require that flash is installed on the user's computer before IE6-7. This means that would be expected that any IE 6-7 users of your site would have to have flash installed in order to use this payment service (could be a potential headache).
Personally I'm not a big fan of adding dependencies user dependencies like this unless I have to, so I would try to implement the proxy solution.
David Ipsen pointed out the Same Origin Policy.
To get around this, you can create a php file on your domain which would curl out to the webservice you want, and change your $post() function to call to the php file on your server via ajax.
Related
I have a project where i'm calling a php file from jquery ajax.Inside the php file i have a curl call to a rest API to have some data.This data flow cannot be altered i.e from jquery i call the php file then from php file the api will be called.Now i have to prevent displaying the url in the firebug console when the ajax call is triggered.Any idea how can i achieve this? Here is the code i used for calling the php file.
$.getJSON("file.php",function(data) {
console.log("hello"+data);
});
Now i have to prevent displaying the url in the firebug console when the ajax call is triggered.
Sorry, not possible. If the user's web browser is making a request, the user can see it. Even if you manage to somehow hide it from the web browser, they can still see it in any number of other tools. Any request that comes from the user's machine can be inspected by the user.
If you absolutely need to make this happen, then you need to write a custom client and perform encrypted communication between that client and your server.
Now to the real question... why should this be hidden from the user? If the user shouldn't see the data, then why is the request being made client-side in the first place? Just make the request from server-side code and keep the data server-side. If the user should see the data, then what's the problem? If the user only shouldn't see the URL but should see the data, get the data server-side and only show the data to the user.
If you have a public URL which is providing requestors with sensitive information and you don't want anybody to know what that URL is, you have a security problem. As mentioned in a comment above, security through obscurity is no security at all.
I have written code in a php file that gets called from Paypal when a charge is processed (also called as PIN/API etc.). Paypal sends some parameters, may be many get and post variables etc. too along with the page call using which I send email to customer based of the user details, amount etc. from the parameters. Is it possible that I can save all the call info by any line of code in the php file so that I can simulate same call again, because Paypal sandbox is very time consuming and if I can debug by code locally instead of writing a log code on each step and transferring the php file on server for testing after each code change, then it will save many hrs.
I hope I am clear in my question. I just want to simulate a page request which third-party server is calling and I don't know their parameters. So, I was thinking may be there is a way to do an exact page request by any mean on my local computer.
You know which parameters Paypal will be sending you, it's in their documentation. But I can understand you might want this for debugging or error reporting.
How to capture input
To capture a request it's usually sufficient to capture $_GET and $_POST. In some cases you will want to read from file_get_contents("php://input") as well but I don't believe PayPal uses that.
How to make a request
If your request is simple you can just do a file_get_contents("mypage.php"). If you want to send POST parameters as well: make a stream context with stream_context_create. Or chicken out and use curl :P
I don't know the proper way to say this, so here is my issue.
I am dealing with an API that sends information to the server, from either web form or whatever in this format:
http://server/non_agent_api.php?source=test&user=6666&pass=1234....
with a bunch more parameters.
Normally, I have dealt with API's that just send it with SOAP or REST, not in a URL like that. My question is how do I send that information using php or something. So if I wanted to take in a username and password from a webform, how do I send that link to the server without clicking on the URL itself.
I hope that makes sense. Thanks for the help.
You can use curl for that like,
Read curl(), here you can find a class which can be easily used.
In PHP use
header("Location: TARGETURL");
Create the TARGETURL using the information sent from the form.
The Location Header makes the server to generate 302 Moved temporarily HTTP return code. The browser then sends the user to the TARGETURL transparently without any further interaction.
Although i'd say i'm fairly savvy with pinging off POST & GET requests one thing i'm not too savvy with is HTTP Headers.
I'm attempting to fire some POST requests to a few scripts to try and debug them - however, I need to be logged in (within the request) for it to work.
Whats the best way to achieve this. The app's auth login is done with simple PHP sessions.
This is broad question but here are my 2 cents.
As your tag suggests, you are already aware of cURL, so you can utilize that and look into the CURLOPT_COOKIEJAR which would help you maintain the cookie. You can just google for some code samples like for instance this one which I just found very casually
PHP, cURL post to login to WordPress
It just gives you some idea of how the script will look like.
There is another option if the application code is available to you. You can just hack in a fake valid user based on some temporary/special GET parameter that you send and you can remove/disable this code outside of production.
I'm building out an API and have a question about how to track/know which domains use the call.
The API call is built in PHP, and doesn't require any authentication. A user will most likely use the API in an AJAX call on their server.
So for example, my domain that is serving up the API PHP file is called dev.yourmapper.com. Someone on the domain www.metromapper.org builds a page that creates a Google map, and calls my file using Ajax to overlay my data on their map.
Here is that example in action: http://www.metromapper.org/example/apitest.htm
(Click the center map marker to see a popup of all the PHP Server variables available to the yourmapper.com script.)
Note that HTTP_REFERER is likely going to be 'stackoverflow.com' if you click the link (or empty if you cut and paste the link). I would think that the referer would be metromapper.org, since that domain calls the yourmapper.com script after it loads, but apparently not.
Bottom line: what method can I use to determine which domain is calling my yourmapper.com script with Javascript? I can use other languages besides PHP if needed. Thanks.
"I would think that the referer would be metromapper.org, since that domain calls the yourmapper.com script after it loads"
That's incorrect actually. Firstly you should never rely on the HTTP_REFERER because it's a voluntary parameter passed by most (not all) browsers, and it can easily be spoofed. I can send your website requests using CURL that make it look like the referrer was whitehouse.gov if I want to. There's no security measures in place there.
That being said. The browser sets that parameter to the page that referred the user to the currently loaded page. Not script. So the reason you see the result you're seeing is because the user was referred to metromapper.org by a link on stackoverflow.com
Finally, let's get to the juicy part. You're using JS to code things in the browser. That's fine and there's absolutely no problem with that. But you have to remember that JS is open source. So people can (and will) mess with your code to play with your API just because they can. That being said. Your best bet is probably to pass the url of the site along with the request in your JS api. That's the best way to "track" what sites are using your script. You could check server side to make sure that a URL was passed. That would prevent people from modifying your API to remove the bit that sends their URL to your server. It won't, however, prevent them from modifying it to use someone else's url or a random unregistered one as the parameter.
Sure you could build a PHP API that they run on their server. The JS API connects to the PHP API and the PHP API is zend-guard encoded (or some other source protection code system) but then there's still going to be people who decode the file to get back to your source and mess with you. Granted there'd be far less people able to do that, and the average user would just rather use your API as it is. Then you also have the issue of people not being able to run your API on servers that don't have the ability to run encoded PHP files.
In the end you have to determine your level of desired security and authentication, but since your API is running in JavaScript in the client browser, there is very little available beyond obfuscation.
I'd say your best option would be to simply have your JS code snag the URL of the current page and send it with the API request. From there your server can process the URL to get the root domain and any other info you want to store.
If you want to prevent people from "spoofing" requests for other user's website urls, you could implement a PHP API that gets installed on the user's server at a certain place. For example http://www.domain.com/my-app-name.php
All JS API calls should go through that script. When the user downloads your API they should enter their website URL and some other info. Your system generates a "key" and injects it into the script before packaging it for them to download. That key is valid for their domain and used to encode all transmission to/from your API using say blowfish or another 2-way encryption algorithm. This way when your API receives a request from their PHP API file, you're getting the url of the page that request was made from, encoded with a key that only you and the admin of that site have. So the request comes through as something like this: metromapper.org/api?site=[url_encoded_page_address]&req=[encrypted_request]
Your server uses the page url to determine what key should be used to decrypt the data. It then decrypts the data. If the data is corrupted or doesn't decrypt into what you expect, then it's an invalid request and you should just exit returning nothing.
The reason I suggest using a PHP file for encryption as opposed to writing the encryption into JS is because you don't want to burden the client (each site visitor) with the load of encryption/decryption and PHP is going to handle it much faster than JS would since there are libraries made to handle those tasks for you.
At any rate that should get you on the right track to being able to keep track of and validate requests for different sites against your API.
You could generate a hash based on the domain name, and let the users of your API send the domain name and the hash in each request. Now since you're API uses PHP you'll have set the 'Access-Control-Allow-Origin' somewhere in the header. If you do this in PHP you can play around with that a bit. The script below is a simple example of an implementation that doesn't require php on the caller side (domain that uses you're API).
Caller Side (no php required):
<script type="text/javascript">
function callA() {
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "//ajaxdomain.com/call.php?"+
"dom=www.callerdomain.com&"+
"key=41f8201df6cf1322cc192025cc6c5013",
true);
xhttp.onreadystatechange = function() {
if(xhttp.readyState == 4 && xhttp.status == 200) {
handleResponse(xhttp.responseText);
}
}
xhttp.send();
}
</script>
Ajax Server Side (PHP):
<?php
if($_GET['key']==md5($_GET['dom']."Salt")) {
header("Access-Control-Allow-Origin: http://".$_GET['dom']);
}
?>
This way the header would also be placed if the call came from a malicious domain, but rest will bounce because of a Cross Origin Exception, and thus no result will be given.
For the sake code space I used a md5 hash in this example, but you could use more complex hashes if you want. Note that you should (as always) keep the used salt secret.
I put a working example online at the following (sub)domains. The pages are identical.
cors1.serioushare.com - Only works on 'CORS 1' button.
cors2.serioushare.com - Only works on 'CORS 2' button.