I am using a DocuSign API and have run into some issues.
When sending the data request to their server I am getting the following error:
SoapFault exception: [q0:InvalidSecurity] An error was discovered
processing the <Security> header ---> WSE065: Creation time of the
timestamp is in the future. This typically indicates lack of synchronization
between sender and receiver clocks. Make sure the clocks are synchronized
or use the timeToleranceInSeconds element in the microsoft.web.services3
configuration section to adjust tolerance for lack of clock synchronization.
I have looked all over their community forums and the only response I can find from their forum admin is this:
The message means that the client clock is wrong. The timezone might be set
incorrectly. If the SOAP request is timestamped too far in the future or in the
past, the server will reject it. We generally run into this error with mobile
apps since folks don't always have their devices set to sync to network time.
I checked my server time as well as my computer time to make sure everything is fine. My computer time is set to EST, and the server is set to CST. I have tried updated and synchronized my system clock on my computer as well as trying to adjust my timezone to CST to make sure they both match. I have also changed my computer time to GMT because that is what they say their server time is. I have also tried updating my server's clock since it seems to be the one that is a little bit off. (there seems to be like a 6 minute difference between my clock and the server clock).
I ran this command on the server:
sudo ntpdate ntp.ubuntu.com
Response:
27 Sep 08:51:41 ntpdate[18858]: step time server 91.189.94.4 offset -357.639332 sec
I also tried editing my grub configuration file on the server (/boot/grub/grub.conf). I tried adding different combinations of these params to the end of the kernel line:
clock=pit
acpi=off
noapic
As well as trying to update the hardware clock with this command:
hwclock=systohc
The soap headers are as follows:
This request was sent out at 10:41AM(my computer time [EST]), 9:47AM (my server time [CST]).
Request:
POST /api/3.0/api.asmx HTTP/1.1
Host: www.docusign.net
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.3.16
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.docusign.net/API/3.0/CreateEnvelope"
Content-Length: 116157
Response:
HTTP/1.1 500 Internal Server Error
Cache-Control: private
Content-Length: 1696
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Thu, 27 Sep 2012 14:41:13 GMT
Vary: Accept-Encoding
Strict-Transport-Security: max-age=7776000; includeSubDomains
If anyone has any thoughts as to what might be causing this error, or if anyone has any further advice on how to go about synchronizing my clocks, I would love to hear them.
Thanks in advance for your time and consideration.
I ended up contacting the company I am hosting my virtual server with and as it turns out it wasn't an issue with anything I have control over at all. It turned out that their hypervisor (virtual machine monitor - VMM) was having issues so when my server was synchronizing its time from it, my time was getting offset by about 7 minutes. Since the system clock of my server was being controlled by it, this also disallowed me from being able to set the time manually with this command:
date -s "27 SEP 2012 HH:MM:SS"
since the changes would just be superseded by the VMM.
Related
I have come across this header for the first time and not sure what it does or mean. I have searched around and couldn't find what I was looking for.
I am trying to consume a SOAP API using PHP SoapClient class and it's returning an empty response and these response headers. Also, no exception is thrown.
HTTP/1.1 200 OK
X-Backside-Transport: FAIL FAIL,FAIL FAIL
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml
Date: Tue, 21 Jun 2016 20:09:50 GMT
X-Client-IP: xx.xxx.xxx.xxx
Any help is appreciated.
It seems that the web service you're trying to communicate is behind the xml firewall (probably IBM DataPower, it does send X-Backside-Transport header on failere) and blocks the error response (aka. fault message). This is the default behaviour for the xml firewalls. Root cause can be malformed soap message (i.e.: wrong data type) or an server site exception.
In order to solve the problem, you should contact with the web service owner.
I've seen this in the past when communicating with IBM Backends, in my experience it has also been joined with a HTTP 401 Unauthorised.
The reason for the error on my side was because of duplicate headers (e.g. sending the same head twice...)
Hope this helps.
I have an application (CakePHP 2.2) that worked fine up until lately, however all of a sudden it's started only delivering part of the page. The HTML for the page is truncated, however it doesn't always truncate at exactly the same place each time (although it's about the same place).
I've had someone else test this from another location & they also experienced the same problem.
The first time I had this problem I restarted the server & it appeared to resolve the problem, however it's happened again. This time I've tried restarting Apache, rather than the whole server & it does not appear to have resolved the problem.
I'm not sure what else to try, so any suggestions welcome.
Thanks in advance.
Update: I've also now tried disabling APC but the problem continued after this was disabled.
Another update: Having tried adding content above & below the point it was truncating, it would appear that it is truncating at a certain distance from the end of the file, as the approximate break point only moved when content is added after where it's breaking.
Yet another update...
OK, so I've done even more digging & there seems to be a problem with the calculation of the content length on my production server. Here's the output from my digging (Date headers stripped to save space)...
Server with Content-Length unset
If I unset the Content-Length header in the CakeResponse::_setContentLength(), the full page displays fine, & this is the header returned…
Connection close
Server Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_bwlimited/1.4
Transfer-Encoding chunked
X-Powered-By PHP/5.3.24
Server with Content-Length set
If I don't unset the Content-Length header then the page displayed is truncated, & the response headers are…
Connection close
Content-Length 2455
Content-Type text/html; charset=UTF-8
Server Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips mod_bwlimited/1.4
X-Powered-By PHP/5.3.24
Local Machine with Standard Content-Length
I would think it's the header length calculation, apart from the fact that on my local machine, even without unsetting the Content-Length header, the full page displays, even though the Content-Length returned is the same as on the production server...
Connection Keep-Alive
Content-Length 2455
Content-Type text/html; charset=UTF-8
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8x
X-Powered-By PHP/5.3.15
From what I can gather,
the script must be die'ing and then stopping the HTML after the die code from displaying.
You need to look further into the code of CakePHP, and check that the logical functions are not ending unexpectedly and that there is no outstanding die function that could cause the HTML from loading.
I'm accessing a remote SOAP Service that tends to be reacting very slow from time to time (we're talking about more than 10 seconds here).
System is PHP Version 5.3.1, running on Windows Server 2003.
My client is set up like this:
new SoapClient($wsdl, array("trace" => true, "exceptions" => true, "cache_wsdl" => WSDL_CACHE_BOTH, "connection_timeout"=>5000));
Now when I'm shooting a request that takes more than about 10 seconds, the following happens: I get the late but correct response from the service, together with a 200 header (taken from SoapClient::__getLastResponse)
Response Headers:
HTTP/1.1 200 OK Via: 1.1 XXX Connection: Keep-Alive Proxy-Connection: Keep-Alive Content-Length: 430 Date: Mon, 10 Oct 2011 16:03:15 GMT Content-Type: text/xml;charset=UTF-8 Server: Microsoft-IIS/7.5 X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1 X-Powered-By: ASP.NET
But as the SOAP result, I get a SoapFault:
fault:
code: 500
message: An internal error occurred. Please contact our support.
I've tried preventing this with:
ini_set('default_socket_timeout', 5000 );
and setting up the SoapClient with "connection_timeout"=>5000 as seen above. Nothing helps. Any suggestions would be heavily appreciated.
Just had the same problem while accessing a Web Service in SAP and it was not a PHP Bug but a timeout setting in the SAP Web Dispatcher.
I was fighting this for many hours trying to figure out what was wrong with PHP or the SOAP Module.
Finally, I tested in SOAP-UI and the problem was solved quickly. You should do the same with SOAP-UI. Perhaps the Webservice you are calling is depending on another remote connection that has its own timeout settings.
I am running a test server locally that is also broadcasted (for education purposes) on a Mac. I ran a software called acunetix from another computer and it was able to detect the technologies used on the server.
How can I prevent others from viewing the technology my server is running?
Here is one thing you can do to hide the Apache, PHP and OS version information.
Before:
HTTP/1.1 200 OK
Date: Fri, 20 Nov 2009 12:20:30 GMT
Server: Apache/2.2.4 (Ubuntu) PHP/5.2.3-1ubuntu6.4
X-Powered-By: PHP/5.2.3-1ubuntu6.4
Connection: close
Content-Type: text/html; charset=UTF-8
After:
HTTP/1.1 200 OK
Date: Fri, 20 Nov 2009 13:06:21 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=UTF-8
Also, make sure that you have custom error pages so that they don't reveal information about Apache and PHP.
1)Using mod_security you can change your ServerSignature to somthing compeltely different like this:
SecServerSignature "Microsoft IIS"
Without mod_security, your http header will still say "Apache".
2)Even if you don't have a .php extension you can see if the file is a PHP file by doing this:
http://digg.com/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
This url will display::
To stop this image hack and other issues, make sure this is set in your php.ini:
expose_php=Off
Also make sure:
display_errors=off
and:
session.name=session_id
3)For more fingerprinting try nmap -sV yourdomain.com, often times ssh will leak detailed information like what Linux distro you are running. I recommended disabling what you can and hiding the rest with port knocking.
Iptables for linux, or use .htaccess file in www-root-dir
Order Deny,Allow
Deny from all
Allow from local.
Allow from 167.0.2.1, 167.0.2.2
or settings in httpd.conf
The HTTP/1.1 RFC stipulates "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response." I know Apache honors the RFC but modules don't have to. My question is, does mod_php5 honor this?
The reason I ask is because I just came across an article saying that PHP developers should check this themselves with:
if (stripos($_SERVER['REQUEST_METHOD'], 'HEAD') !== FALSE) {
exit();
}
I googled a second and not much turned up, other than some people saying they try to strange things like mod_rewrite/redirect after getting HEAD requests and some old bug ticket from like 2002 claiming that mod_php still executed the rest of the script by default. So I just ran a quick test by using PECL::HTTP to run
http_head('http://mysite.com/test-head-request.php');
while having:
<?php error_log('REST OF SCRIPT STILL RAN'); ?>
in test-head-request.php to see if the rest of the script still executed, and it didn't.
I figure that should be enough to settle it, but want to get more feedback and maybe help clear up confusion for anyone else who has wondered about this. So if anyone knows off the top of their head (no pun intended) - or have any conventions they use for receiving HEAD requests, that'd be great. Otherwise, I'll grep the C source later and respond in a comment with my findings. Thanks.
The HEAD method is identical to GET
except that the server MUST NOT return
a message-body in the response.
That is why the check should not be performed. Clients should have confidence that HEAD requests process just the same as if a GET was issued (database connection, processing, etc...).
Addendum:
When performing
HEAD /test.php?a=3 HTTP/1.1
Host: somesite.com
PHP will still fill $_GET (and $_REQUEST) with the variables placed in the query string even though it was not a GET request. This allows compliance with the HEAD definition.
I just did a quick test with a PHP file, temp.php, which contains this portion of code :
<?php
echo "Hello, World!\n";
die;
Sending an HTTP GET request to that file gets me the content of the page :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:17:35 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Length: 14
Content-Type: text/html
Hello, World!
While sending an HTTP HEAD request doesn't :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:17:50 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Type: text/html
Not sure this is always true, though...
I remember a situation (some time ago ; was PHP 5.1) in which I've had to test myself, in the PHP code, if I was getting a GET or a HEAD request.
EDIT : After an additionnal test
I just did another test : my temp.php file now contains this :
<?php
file_put_contents('/tmp/a.txt', $_SERVER['REQUEST_METHOD'], FILE_APPEND);
var_dump($_SERVER['REQUEST_METHOD']);
die;
Sending an HTTP HEAD request, I get this :
$ telnet localhost 80
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD /temp/temp.php HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Thu, 08 Apr 2010 20:21:30 GMT
Server: Apache/2.2.12 (Ubuntu)
X-Powered-By: PHP/5.3.2RC2
Vary: Accept-Encoding
Content-Type: text/html
Connection closed by foreign host.
Here, no output.
BUT, looking at the /tmp/a.txt file :
$ cat /tmp/a.txt
HEAD
So : no output sent by the server doesn't mean that there is nothing done ;-)