In php there is also method or functionality which can be used to receive data without GET,POST and REQUEST.
Which is
$input_date_from_client ...
For further actions, you may consider blocking this person and/or reporting abuse
Cool, never heard of this before! 👍
I always try to use either built-in functions/methods from framework I use or
filter_input
:Mathiu, filter_input() and php://input are 2 totally different things:
filter_input() is a function that takes the type of the input along with the variable's name and applies a certain FILTER on it.
php://input is a stream (which is why it is read by file_get_contents()) which allows you to read raw data from the request body.
If you post some 'data' in a text input named 'var' in a form, this is what you will get:
$_POST['var'] will have the value: 'data'
file_get_contents('php://input') will have the value: 'var=data'
FUN fact: php://input is not available with enctype="multipart/form-data"
Thanks for the explanation, I guess there are different use cases for
php://input
then.P.S. Now I'm curious what happens when you have the same var name in GET and POST at the same time.
You will have $_GET['var'] and $_POST['var']. No problems.
$_GET and $_POST are arrays, so you will have no issues for them containing the same variable names.
However, if register_globals was ON (which is removed as of PHP 5.4), then you would look at the variables_order (EGPCS for example). In case it was EGPCS, then Post comes after Get, so the value of $var will be that of $_POST['var'].
That's a good question, I would imagine it would depend on how the application handles global vars and in which order.
For context, here is why it works and how it is different from from Post, Get and Request (mainly Post):
The PHP superglobal
$_POST
, is only supposed to wrap data that is eitherapplication/x-www-form-urlencoded
(standard content type for simple form-posts) ormultipart/form-data-encoded
(mostly used for file uploads)This is because these are the only content types that must be supported by user agents.
By contrast,
file_get_contents('php://input');
will get all the raw data from the request regardless of its type and is left for you to interpret/parse as you will.Source with more detials: stackoverflow.com/a/8893792
Yes. I basically used this to get JSON String.
It's too esoteric and possibly unsecure