I've been trying to receive HTTP requests with custom fields in the headers but it seems like my server removes them...
This is the request that I am sending to the server (I read that request with a HTTP Proxy) :
POST /oauth.php/request_token HTTP/1.1
Host: domain.com
User-Agent: DearStranger/1.0 CFNetwork/485.12.7 Darwin/10.6.0
Authorization: OAuth realm="", oauth_consumer_key="ebb942f0d260b06cb533c6133c28408004d343197", oauth_signature_method="HMAC-SHA1", oauth_signature="qPBFAa8XRRbor2%2F%2FQXv6kU3%2F7jU%3D", oauth_timestamp="1295278460", oauth_nonce="E7D6AC76-74CE-4951-8182-7EBF9B382E7E", oauth_version="1.0"
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Pragma: no-cache
Content-Length: 0
Connection: keep-alive
Proxy-Connection: keep-alive
I printed the headers of the request when I arrive on my page.php. I see that :
uri http://domain.com/oauth.php/request_token
parameters
headers Array
.... Accept : */*
.... Accept-Encoding : gzip, deflate
.... Accept-Language : en-us
.... Connection : keep-alive
.... Host : domain.com
.... User-Agent : DearStranger/1.0 CFNetwork/485.12.7 Darwin/10.6.0
method POST
when I should be seeing that (it is working on a local version)
uri http://localhost:8888/oauth.php/request_token
parameters
headers Array
.... Accept : */*
.... Accept-Encoding : gzip, deflate
.... Accept-Language : en-us
.... Authorization : OAuth realm="", oauth_consumer_key="582d95bd45d455fa2e5819f88fc0c5a104d2c7ff3", oauth_signature_method="HMAC-SHA1", oauth_signature="agPSFdtlGxXv2sbrz3pRjHlROOE%3D", oauth_timestamp="1295272680", oauth_nonce="667A133C-5071-48AB-9F13-8146425E46B7", oauth_version="1.0"
.... Connection : keep-alive
.... Content-Length : 0
.... Host : localhost:8888
.... User-Agent : DearStranger/1.0 CFNetwork/485.12.7 Darwin/10.6.0
method POST
I am using php 5.2.17 on the server.
Do you have any idea to help me fix that issue?
Thanks!
Actually, there is a pretty easy fix. The fault lays with fastcgi. You can just provide an .htaccess file with a rewrite rule to save the header.
<IfModule mod_rewrite.c>
...
# Pass Authorization headers to an environment variable
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>
Credit goes here: https://drupal.org/node/1365168
They also talk about an even simpler solution to let these headers pass through, if you are using a virtual host.
Apache strips the Authentication header because it's a security risk, when used with CGI. Are you using PHP through CGI?
I think PHP also strips Authentication in some circumstances. Again, there's a risk that exposing it to scripts will allow one users' code to sniff other users' on the same server (e.g., if Alice and Bob both have accounts).
Please include the actual names of the headers that are being cut. This question is useless in its present form, forcing us to guess...
Have you checked with Firebug/HTTPFox that your browser's actually sending those headers? Unless you've specifically configured the server to clean up the headers, it's going to pass-through any custom ones as-is.
The Authorization header, which is where the OAuth data gets sent, would ONLY be sent by a client in response to a server-side 401 "authorization required" request. If you haven't added the server-side "must have password to get in" configuration, the client's not going to send auth info.
Related
A while ago I implemented a Soap connection with the Dutch Vecozo company retrieving insurance information for Dutch citizens. Now Vecozo has announced to migrate their server to an Azure environment and therefore I need to change the URLs. My SoapClient is constructed with their supplied wsdl which they supplied years back. However they did not supply a new wsdl file for the new Azure server. They just indicated that the old URL need to be changed to https://api.vecozo.nl/cov/vz801802/v1/soap11
To implement this I added the location and uri option parameters. Also I added __setLocation. However since the connection was also working before, and still after this change, how do I know it actually goes to the new Azure server (they have them both parallel running until Jan 2021)? Did I implement the URL correctly? Any suggestions how to do this otherwise?
$soap_options = array('local_cert'=>$certFile,
'trace'=>1,
'location' => "https://api.vecozo.nl/cov/vz801802/v1/soap11",
'uri' => "https://api.vecozo.nl/cov/vz801802/v1/soap11",
'soap_version'=>SOAP_1_1);
$client = new SoapClient($wsdl_incoming_flat, $soap_options);
// new url 2021
$client->__setLocation('https://api.vecozo.nl/cov/vz801802/v1/soap11');
If I examine my soap header before it was;
POST /v1/VZ801802.svc/soap11 HTTP/1.1
Host: covwebservice.vecozo.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://schemas.vecozo.nl/VZ801802/v1/Controleer"
Content-Length: 897
After the location change it became;
POST /cov/vz801802/v1/soap11 HTTP/1.1
Host: api.vecozo.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.4.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://schemas.vecozo.nl/VZ801802/v1/Controleer"
Content-Length: 897
I think this is what Vecozo means with changing the url. The Host and POST changed..
I implement login in laravel on login request there is two token generate one in body and another one is in header cookie.
When i remove value of body token it's show page expired error but when I remove value of xsrf-token it's not shows any error and login getting succesfull
POST /login HTTP/1.1
Host: <host>
Content-Length: 513
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: <Origin Address>
Content-Type: application/x-www-form-urlencoded
User-Agent:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Cookie: XSRF-TOKEN=<token>; laravel_session=<session token>
Connection: close
_token=<token>&userName=<userName>&password=<Password>
Anyone help me to explain this both token. and why page is not getting expired on remove value of xsrf-token value using burpusite tool.
as mentioned in laravel document:
Laravel makes it easy to protect your application from cross-site
request forgery (CSRF) attacks. Cross-site request forgeries are a
type of malicious exploit whereby unauthorized commands are performed
on behalf of an authenticated user.
also:
Laravel stores the current CSRF token in an encrypted XSRF-TOKEN
cookie that is included with each response generated by the framework.
You can use the cookie value to set the X-XSRF-TOKEN request header.
This cookie is primarily sent as a convenience since some JavaScript frameworks and libraries, like Angular and Axios, automatically place its value in the X-XSRF-TOKEN header on same-origin requests.
I am trying to create a RESTful web service and have gotten stuck on implementing PUT requests. I have tried and failed to follow other answers on this site and various articles from Mozilla.
The request is generated from the domain wwwtest.dev-box and it's going to test.dev-box (basically a front-end app calling the back-end app). Here are the headers I have captured from Live HTTP headers:
http://test.dev-box/resource/v1/data/user/1
OPTIONS /resource/v1/data/user/1 HTTP/1.1
Host: test.dev-box
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: http://wwwtest.dev-box
Access-Control-Request-Method: PUT
Connection: keep-alive
HTTP/1.1 405 Method Not Allowed
Date: Wed, 16 Oct 2013 16:15:58 GMT
Server: Apache/2.2.15 (Red Hat)
x-powered-by: PHP/5.3.27
Access-Control-Allow-Origin: http://wwwtest.dev-box
Access-Control-Allow-Methods: POST, GET, PUT, OPTIONS
Access-Control-Max-Age: 1728000
Content-Length: 0
Allow: PUT
Cache-Control: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8
I'm using a framework so everything is routed to web.php, which contains the following code at the top of the page (taken from this MDN article):
if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {
header('Access-Control-Allow-Origin: http://wwwtest.dev-box');
header('Access-Control-Allow-Methods: POST, GET, PUT, OPTIONS');
header('Access-Control-Max-Age: 1728000');
header("Content-Length: 0");
header("Content-Type: text/plain");
} else {
header("HTTP/1.1 403 Access Forbidden");
header("Content-Type: text/plain");
}
Before my code makes the PUT request it sends the CORS preflight OPTIONS request first (as you can see from the capture above). The necessary headers should be attached to the response and tell the requester that PUT is allowed. Unfortunately as you can see from the response headers above it is still returning 405 Method Not Allowed even though PUT is in the response access-control-allow-methods.
This is the .htaccess file for the framework I'm using (Silex):
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ web.php [QSA,L]
</IfModule>
I've found the answer to be a cross between Apache and framework configuration.
For the Apache config you can either put the following into your VirtualHost directive, or in the .htaccess file of the requested domain (if it's in the .htaccess remember to encapsulate with IfModule mod_headers.c tags). Setting the headers on the page that mod_rewrite redirects to does not work:
Header set Access-Control-Allow-Origin "http://wwwtest.dev-box"
Header set Access-Control-Allow-Methods "GET,POST,HEAD,DELETE,PUT,OPTIONS"
For the Silex config, place the following into your application routes. It basically sends an HTTP 200 OK for any OPTIONS request it receives. Code found on the Silex Google Group:
$app->match("{url}", function($url) use ($app) {
return "OK";
})->assert('url', '.*')->method("OPTIONS");
Both steps need to be completed for the RESTful application to function properly.
The 405 is in reference to the actual preflight/OPTIONS request. Your server is rejecting the preflight outright as OPTIONS requests in general are not accepted by your server. You'll need to modify your server configuration to accept OPTIONS requests. Simply including code in a PHP file may not be enough. Most likely your web/application server is not aware of this verb and is rejecting the request before it hits your PHP code.
On the embedded device I'm working on, the web-pages' Javascript sends requests to local PHP files and then uses the responses to update DOM elements dynamically. Everything works fine: AJAX is cool.
Annoyingly, though, all the responses are gzip encoded even though I'd rather they weren't (the target device's processor doesn't have much processing bandwidth). The problem is that I can't see how to disable gzip compressing the responses.
Note that:
(1) On the server side, I'm testing using PHP 5.3.10 and Apache/2.2.22 under Ubuntu
(2) On the client side, I'm using Firefox 19.0 and Firebug
(3) The PHP files are just echoing their output, i.e. I don't think they're invoking ob_gzhandler()
(4) The JavaScript is using GET rather than POST (it's what was specified for the project)
According to Firebug, the request headers look lke this:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-gb,en;q=0.5
Cookie PHPSESSID=<whatever>
Host 10.0.2.15
Referer http://10.0.2.15/pages/status.php
User-Agent Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
And the response headers typically look like this:-
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection Keep-Alive
Content-Encoding gzip
Content-Length 59
Content-Type text/html
Date Wed, 13 Mar 2013 12:08:02 GMT
Expires Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive timeout=5, max=43
Pragma no-cache
Server Apache/2.2.22 (Ubuntu)
Vary Accept-Encoding
X-Powered-By PHP/5.3.10-1ubuntu3.5
Approaches I've already tried (but without any success):-
(a) Preventing php files' output from being gzipped via the local .htaccess file
<IfModule mod_env.c>
SetEnvIfNoCase Request_URI "\.php$" no-gzip dont-vary
</IfModule>
This was as per http://support.modwest.com/content/1/117/en/how-do-i-turn-off-webservers_-gzip-compression.html but didn't seem to have any effect, even when I restarted apache2 between calls.
(b) Preventing php files' output from being gzipped via the /etc/apache2/httpd.conf file
<Directory /myfolder>
RemoveOutputFilter php
</Directory>
This also didn't seem to have any obvious effect, even when I restarted apache2 between calls.
(c) Setting the "Accept-Encoding" header to "" or "identity" using XMLHttpHeader.setHeaderRequest()
I tried both
xmlhttp.setRequestHeader("Accept-Encoding", "identity");
...and...
xmlhttp.setRequestHeader("Accept-Encoding", "");
Neither seemed to have any obvious effect: Firebug still reports that the request header holds
Accept-Encoding gzip, deflate
I checked the spec for this, and it seems as though setRequestHeader() should be allowed to change the AcceptEncoding header line, so this is a bit odd. Possibly a FF security hole that's been filled?
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#dfn-setrequestheader
Note that the setRequestHeader() mechanism is apparently working ok, because adding...
xmlhttp.setRequestHeader("X-FavouriteFruit", "banana");
...adds a line to the Firebug request output:
X-FavouriteFruit banana
Basically, I'm pretty much out of ideas. How else can I stop my php responses being gzipped?
it would seem you use apache on the device to serve the PHP files, which means you could try something like this in /etc/php.ini (or in .htaccess via #php_value)
zlib.output_compression = Off
in the Language options section.
I am looking to put together a website that displays the full HTTP Request Headers and HTTP Response Headers for the loading of the page itself. For instance. If someone browses to http://example.com/index.php , I want the following to display:
HTTP Request
GET /index.php HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
HTTP Response
HTTP/1.1 200 OK
Date: Mon, 21 Dec 2011 10:20:46 GMT
Server: Apache/2.2.15 (Red Hat)
X-Powered-By: PHP/5.3.3
Content-Length: 1169
Connection: close
Content-Type: text/html; charset=UTF-8
We were able to get the Request header to display fairly simply using the following PHP code:
print $_SERVER['REQUEST_METHOD']." ".$_SERVER['REQUEST_URI']." ".$_SERVER['SERVER_PROTOCOL']."<br>";
foreach (apache_request_headers() as $name => $value)
echo "$name: $value<br>";
But are having some difficulties with the HTTP Response header. Anyone have any ideas of how we can do this? It does not have to be PHP if you have a method that works in Perle or CGI or whatever.
To be clear, I don't mean to set the HTTP Response to anything specific, only display the response served by the web server to load the page.
You want to use headers_list()
http://www.php.net/manual/en/function.headers-list.php
headers_list() will return a list of headers to be sent to the browser / client. To determine whether or not these headers have been sent yet, use headers_sent().
Well here is the issue, the response header is generated after the PHP (or any server-side language for that matter) has already completed its job.
To put it in english its like the post man handing you a letter and you asking him to explain how the process of handing you the letter went. He will probably just look at you dumb.
You will need a client-side language (ie. JavaScript) to perform this task.
Use PHP to get the headers sent to the web Server.
http://www.php.net/manual/en/function.apache-request-headers.php
Use JavaScript to get headers sent by the web server. I would suggest using jQuery for that.
http://api.jquery.com/jQuery.ajax/#jqXHR
This way you are sure that you get all the headers which are either received by the web server or the browser.
Check out get_headers in PHP Manual