0

I'm sending data via ajax to my server (PHP), I'm setting the call to be a POST request, but somehow it doesn't work that way and works as a GET request, here's the code:

$.ajax({
 type: 'POST',
 data: {
     user: user
 },
 url: url,
 crossDomain: true,
 contentType: "application/json; charset=utf-8",
 dataType: 'jsonp',
 success: function (data) {
     alert(data);
 },
 error: function (error) {
     alert(error)
 }
});

PHP:

<?php
$user = $_POST["user"];
echo $user;
?>

That doesn't work, but if I change the $_POST to $_GET, it works great.

What is it that I'm doin wrong that the server intepretes GET and not POST as I want and as I'm setting it in the ajax call?

Apul Gupta
  • 3,044
  • 3
  • 22
  • 30
Agustín
  • 1,546
  • 7
  • 22
  • 41

1 Answers1

1

You have a couple of problems.

This line:

dataType: 'jsonp',

… causes your request to make a JSONP request. The data is send by adding a <script> element to the document and the response must be encoded as JSONP. Your response is not encoded as JSONP, it is a plain text response.

Remove that line.

Note that since you are using PHP, it will default to having a text/html content type for the response. Since you are echoing user input directly out from your script, you are vulnerable to an XSS attack. Either encode your output as HTML (with htmlspecialchars) or state that you are sending plain text:

header("Content-Type: text/plain");

This line:

contentType : "application/json; charset=utf-8",

…makes your HTTP request claim you are sending JSON but:

  1. You aren't, you are sending application/x-www-form-urlencoded data
  2. PHP doesn't decode JSON formatted requests automatically (so it wouldn't populate $_POST)

Remove that line. You'll use the correct content type (because the default is correct) and PHP will populate $_POST (because it does does that automatically for application/x-www-form-urlencoded data).

(It works when you use a GET request because the data gets encoded in the query string instead, and the content type header is ignored because there is no content to describe the type of).

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • or, alternatively, encode the payload as json, which clearly makes sense. – arkascha Oct 26 '14 at 16:52
  • @arkascha — Given the PHP in the question doesn't decode JSON, that wouldn't make sense. – Quentin Oct 26 '14 at 16:53
  • Obviously you'd have to match the sides, you are right. Thought that was obvious, my fault. – arkascha Oct 26 '14 at 16:54
  • Still not a good idea though. You have to write more code to encode it and more code to decode it, which is just more opportunity for something to go wrong. – Quentin Oct 26 '14 at 16:55
  • But it saves you from having to take care of encoding manually, which is much more work in the end. – arkascha Oct 26 '14 at 16:55
  • jQuery **already** saves you from having to take care of encoding manually. That's why the solution is to simply remove the one line I pointed out. – Quentin Oct 26 '14 at 16:56
  • crossDomain just makes jQuery do all the extra stuff (like disable custom extra headers) that it does on a cross domain request when you make a non-cross domain request (include your local server redirects to a cross-origin server). – Quentin Oct 26 '14 at 17:04
  • Having fixed the problems described in your original question, your new problem is a duplicate of [this question](http://stackoverflow.com/questions/3076414/ways-to-circumvent-the-same-origin-policy). – Quentin Oct 26 '14 at 17:05