Open elmiquito opened 3 years ago
Here's the upload_crash_report.php code with the new "from" and "to" addresses.
`<?php
/ This script should be installed at http://integralive.org/upload_crash_log.php IntegraLive gui reads this address from its config file IntegraLiveConfig.xml at startup /
$to = "integra.admin@gmail.com"; $from = "c2781106@c2781106.myzen.co.uk"; $subject ="IntegraLive Crash Report"; $message = ""; $uploadCheck = "IntegraLive Crash Report";
$headers = "From: $from";
// quit if not right sort of post if( $_POST[ "upload" ] != $uploadCheck ) { die( "it looks like this post didn't come from the Integra Live GUI so it is being ignored" ); }
// append post variables into message foreach( $_POST as $key=>$value) { $message.= "$key: $value\n"; }
//append user's ip
//REMOVED IP FROM CRASH REPORT TO PROTECT PRIVACY OF REPORTER
//$ip=$_SERVER['REMOTE_ADDR'];
//$message.= "ip: $ip\n";
// boundary $semi_rand = md5(time()); $mime_boundary = "==Multipart_Boundary_x{$semi_rand}x";
// headers for attachment $headers .= "\nMIME-Version: 1.0\n" . "Content-Type: multipart/mixed;\n" . " boundary=\"{$mime_boundary}\"";
// multipart boundary $message = "This is a multi-part message in MIME format.\n\n" . "--{$mime_boundary}\n" . "Content-Type: text/plain; charset=\"iso-8859-1\"\n" . "Content-Transfer-Encoding: 7bit\n\n" . $message . "\n\n"; $message .= "--{$mime_boundary}\n";
// preparing attachments foreach( $_FILES as $uploadedFile ) { $tmpName = $uploadedFile[ "tmp_name" ]; //$fileName = "test.txt"; //$uploadedFile[ "name" ]; $fileName = $uploadedFile[ "name" ]; $file = fopen($tmpName,"rb"); $data = fread($file,filesize($tmpName)); fclose($file); $data = chunk_split(base64_encode($data)); $message .= "Content-Type: {\"application/octet-stream\"};\n" . " name=\"$fileName\"\n" . "Content-Disposition: attachment;\n" . " filename=\"$fileName\"\n" . "Content-Transfer-Encoding: base64\n\n" . $data . "\n\n"; $message .= "--{$mime_boundary}\n"; }
// send
$ok = @mail($to, $subject, $message, $headers); if ($ok) { echo "mail sent to $to!"; } else { echo "mail could not be sent!"; }
?>`
@elmiquito
I think the problem is that Integra Live 1.x is set up to upload to http://integralive.org/upload_crash_log.php. When it attempts to access this URL it gets a redirect to https://integra.io/upload_crash_log.php which it does not follow.
You can test this from the command line with:
$ curl http://integralive.org/upload_crash_log.php
We can confirm that integra.io works with:
curl -X POST --data "upload=IntegraLive Crash Report" "http://integra.io/upload_crash_log.php"
The problem can be fixed without rebuilding IntegraLive, by changing the key in the IntegraLiveConfig.xml in the .app bundle.
<crashreporturl>http://integralive.org/upload_crash_log.php</crashreporturl>
Should be changed to:
<crashreporturl>http://integra.io/upload_crash_log.php</crashreporturl>
We have control on the redirect from integralive.org, would changing it to http:// instead of https:// do the trick as well?
@jamiebullock I changed the key in the IntegraLiveConfig.xml in the .app bundle from
We have control on the redirect from integralive.org, would changing it to http:// instead of https:// do the trick as well?
This won't make any difference. We can see from curl
that integra.io works for both protocols and integrative.org works for neither.
If you have control over the domain settings, I think what you need to do is instead of setting up a permanent redirect from integrative.org to integra.io, is instead modify the DNS settings for integralive.org so it points directly to the integra.io server.
This will effectively give you the same setup you had before.
@jamiebullock I changed the key in the IntegraLiveConfig.xml in the .app bundle from http://integralive.org/upload_crash_log.php to http://integra.io/upload_crash_log.php but I still get the IOErrorEvent when trying to send a crash report. The error message comes up very quickly though, compared to the time it took before.
It's hard to say why this is without going deep into it. It's possible the GUI is sending something the server doesn't expect or support. I would suggest looking at the server logs for clues.
This is the console log when initiating a crash report upolad in Integra Live
default 14:20:55.219930 +0000 Integra Live TIC TCP Conn Start [47:0x60000017f200]
default 14:20:55.220094 +0000 Integra Live Task <4A1D8593-1E9D-4873-A4C8-2C42FB0EB4FB>.<0> setting up Connection 47
default 14:20:55.220134 +0000 Integra Live [47
If you have control over the domain settings, I think what you need to do is instead of setting up a permanent redirect from integrative.org to integra.io, is instead modify the DNS settings for integralive.org so it points directly to the integra.io server.
DNS settings for integralive.org and integralive.com have been changed to those of integra.io. Aliases and redirects added for both on the Zen Internet cPanel to point to the integra.io home directory.
The Issue is also found in Windows
Log Name: Application Source: Application Error Date: 13/01/2021 11:52:27 Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: bcu Description: Faulting application name: IntegraServer.exe, version: 1.7.11.3322, time stamp: 0x59ce5d2b Faulting module name: libIntegra.dll, version: 1.7.11.3322, time stamp: 0x59ce5345 Exception code: 0xc0000005 Fault offset: 0x00084aa0 Faulting process ID: 0x1618 Faulting application start time: 0x01d6e9a25788b6f5 Faulting application path: C:\Program Files (x86)\Integra Live\server\IntegraServer.exe Faulting module path: C:\Program Files (x86)\Integra Live\server\libIntegra.dll Report ID: c28b72b2-ac3c-48dc-b9c4-a6b2f1db6e37 Faulting package full name: Faulting package-relative application ID: Event Xml:
@Richc @elmiquito Sorry... for clarification when I wrote "I would suggest looking at the server logs for clues" I meant the web server. To see if there are any HTTP error messages etc. This might help tell why the HTTP requests from IL are failing. The absence of any errors OTOH, would suggest a problem in IL itself.
But, if it's going to be time consuming, I'm not sure it's worth going much further with this since even if you manage to get valid crash reports back from users, there's not a lot that can be done about it until there's a new version of IL that can be shipped out with fixes.
@jamiebullock I checked the error_log file on the server, and there's nothing at all. Just to check I've missed something, the server logs I checked are /public_html/integra.io/error_log, /public_html/integra.io/wp-includes/error_log and the Errors page on cPanel. It looks like the HTTP requests never get to the server. I can't really decipher most of the logs posted above by Rich and myself, but it looks like there are enough errors to explain why the reports are not being sent by the user's machine. I agree with your point that we can't do much about the crash reports, but at least we can keep them for reference to avoid potential problems in the new version, and it does feel more reassuring to the users if they can send the report without getting an error.
@elmiquito what are you doing to cause the crash? I can try to debug this locally, but I can't make it crash!
@elmiquito what are you doing to cause the crash? I can try to debug this locally, but I can't make it crash!
You can open the attached .ixd file (or any .ixd file for that matter!) from Integra Live. AtTheStillPointOfTheTurningWorld.ixd.zip
Crash Reports fails to upload with IOErrorEvent message (see attached screenshot) even after fixing upload path (see Issue #1024).