@LLPP65 opened this Issue on March 28th 2017

My email reports have an IP address for the host portion of the "Sent from" section at the top of the weekly email report. This causes all the logo and flag images in the report to be blank because the site that serves them is one of many virtual servers on the same IP address.

Sent from http://a.b.c.d/.

I am running the latest version of Piwik, 3.0.2.

@LLPP65 commented on March 28th 2017

Additional data point... The report contains an IP address instead of a host name when the report is sent as a scheduled job. If I manually trigger a report to be sent from the administration interface, then the report is correct and contains a proper host name as part of the "Sent from" URL.

@LLPP65 commented on March 28th 2017

Another data point. The "Sent from" uses the correct hostname un the URL for one server's reports and an IP address in the URL for another. Very confusing.

@LLPP65 commented on May 2nd 2017

This behaviour is still the same in 3.0.4

@dbapl commented on May 7th 2017

Same thing in update notifications:

Hello,

Some plugins you use have been updated on the Marketplace:

 * AOM 0.6.3

Click here to update your plugins now:
https://a.b.c.d/index.php?module=CorePluginsAdmin&action=plugins

Happy analysing!
@mattab commented on September 19th 2017 Member

Maybe we should check that the Piwik URL is found in the trusted_hosts and if not, default to use the trusted_hosts instead?

we'll also need to make sure it works when Piwik is installed in a sub-directory.

@tsteur commented on September 19th 2018 Member
@mattab commented on October 5th 2018 Member

Please reopen if you still experience the issue with the latest Matomo @LLPP65

@LLPP65 commented on October 9th 2018

My latest email reports still contain IP addresses instead of hostnames.

@tsteur commented on October 9th 2018 Member

Just to double check: That'S with 3.6.1? Would it be possible that we debug this issue on your system?

@LLPP65 commented on October 9th 2018

I’m on 3.6.0, I don’t see 3.6.1 available for download. For debugging, just let me know what I can send you and I will do it.

Thanks,
Len

On 9 Oct 2018, at 20:34, Thomas Steur <notifications@github.com> wrote:

Just to double check: That'S with 3.6.1? Would it be possible that we debug this issue on your system?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@mattab commented on October 9th 2018 Member

Would it be possible to send us SSH Access to the matomo server? You can email at matomo.org/contact
Thank you!

@LLPP65 commented on October 9th 2018

Sorry, that isn’t something I can do. If you let me know what you’d like to see (logs, config files, etc.) I can sanitize and send them.

On 9 Oct 2018, at 20:51, Matthieu Aubry <notifications@github.com> wrote:

Would it be possible to send us SSH Access to the matomo server? You can email at matomo.org/contact
Thank you!


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@tsteur commented on October 9th 2018 Member

Sorry meant 3.6.0, 3.6.1 isn't out yet :)

Two things: I'm just seeing the fix will only apply if you delete your current stored Matomo URL. Any chance you can execute this SQL query and check if the error persists?

delete from piwik_option where option_name = 'piwikUrl';

Your table prefix may differ from piwik_.

If it then still uses the wrong URL, and in case you are familiar with PHP/Server could you maybe just for one request apply this file change send us the output of this (make sure to remove the added lines after testing):

diff --git a/core/SettingsPiwik.php b/core/SettingsPiwik.php
index bfd4ab4aeb..616a98cd01 100644
--- a/core/SettingsPiwik.php
+++ b/core/SettingsPiwik.php
@@ -177,6 +177,12 @@ class SettingsPiwik
      */
     public static function getPiwikUrl()
     {
+        $currentUrl = Common::sanitizeInputValue(Url::getCurrentUrlWithoutFileName());
+        $test = Url::getHostFromUrl($currentUrl);
+        var_export('host: ' . $test);
+        var_export($_SERVER);
+        exit;
+
         $url = Option::get(self::OPTION_PIWIK_URL);

         $isPiwikCoreDispatching = defined('PIWIK_ENABLE_DISPATCH') && PIWIK_ENABLE_DISPATCH;
@@ -189,8 +195,6 @@ class SettingsPiwik
             return $url;
         }

-        $currentUrl = Common::sanitizeInputValue(Url::getCurrentUrlWithoutFileName());
-
         // when script is called from /misc/cron/archive.php, Piwik URL is /index.php
         $currentUrl = str_replace("/misc/cron", "", $currentUrl);
@tsteur commented on October 9th 2018 Member

Feel free to anonymize sensitive information from $_SERVER

@LLPP65 commented on October 15th 2018

I cleared the value of piwikUrl in the DB and the emailed report still contains an IP address instead of a hostname. If I force-send a report from the web interface, then it uses the hostname (it gets it from the httpd environmental variables), but not when a scheduled report is sent. Following is the output after modifying the SettingsPiwik.php file, but keep in mind that it is the output of an interactive web session. The problem is when the system sends a scheduled report and does not have the httpd environmental variables available.

'host: u.padilla.net'array ( 'USER' => 'www-data', 'HOME' => '/var/www', 'SCRIPT_NAME' => '/p/index.php', 'REQUEST_URI' => '/p/index.php', 'QUERY_STRING' => '', 'REQUEST_METHOD' => 'GET', 'SERVER_PROTOCOL' => 'HTTP/2.0', 'GATEWAY_INTERFACE' => 'CGI/1.1', 'REMOTE_PORT' => '62776', 'SCRIPT_FILENAME' => '/var/vhosts/u.padilla.net/p/index.php', 'SERVER_ADMIN' => 'len_at_padilla_dot_net', 'CONTEXT_DOCUMENT_ROOT' => '/var/vhosts/u.padilla.net', 'CONTEXT_PREFIX' => '', 'REQUEST_SCHEME' => 'https', 'DOCUMENT_ROOT' => '/var/vhosts/u.padilla.net', 'REMOTE_ADDR' => ‘xxx', 'SERVER_PORT' => '443', 'SERVER_ADDR' => '83.231.195.95', 'SERVER_NAME' => 'u.padilla.net', 'SERVER_SOFTWARE' => 'Apache', 'SERVER_SIGNATURE' => '', 'PATH' => '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'HTTP_HOST' => 'u.padilla.net', 'HTTP_DNT' => '1', 'HTTP_ACCEPT_LANGUAGE' => 'en-us', 'HTTP_USER_AGENT' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Safari/605.1.15', 'HTTP_ACCEPT_ENCODING' => 'br, gzip, deflate', 'HTTP_ACCEPT' => 'text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8', 'HTTP_COOKIE' => ‘PIWIK_SESSID=xxx; xxx=xxx; _pk_id.1.4270=xxx.', 'proxy-nokeepalive' => '1', 'SSL_SESSION_RESUMED' => 'Initial', 'SSL_SESSION_ID' => ‘xxx', 'SSL_SERVER_A_SIG' => 'sha256WithRSAEncryption', 'SSL_SERVER_A_KEY' => 'rsaEncryption', 'SSL_SERVER_I_DN' => 'CN=Let\'s Encrypt Authority X3,O=Let\'s Encrypt,C=US', 'SSL_SERVER_S_DN' => 'CN=u.padilla.net', 'SSL_SERVER_V_END' => 'Dec 12 03:00:06 2018 GMT', 'SSL_SERVER_V_START' => 'Sep 13 03:00:06 2018 GMT', 'SSL_SERVER_M_SERIAL' => ‘xxx', 'SSL_SERVER_M_VERSION' => '3', 'SSL_CLIENT_VERIFY' => 'NONE', 'SSL_CIPHER_ALGKEYSIZE' => '256', 'SSL_CIPHER_USEKEYSIZE' => '256', 'SSL_CIPHER_EXPORT' => 'false', 'SSL_CIPHER' => 'ECDHE-RSA-AES256-GCM-SHA384', 'SSL_COMPRESS_METHOD' => 'NULL', 'SSL_SECURE_RENEG' => 'true', 'SSL_PROTOCOL' => 'TLSv1.2', 'SSL_VERSION_LIBRARY' => 'OpenSSL/1.1.0h', 'SSL_VERSION_INTERFACE' => 'mod_ssl/2.4.29', 'SSL_SERVER_SAN_DNS_0' => 'u.padilla.net', 'SSL_SERVER_I_DN_CN' => 'Let\'s Encrypt Authority X3', 'SSL_SERVER_I_DN_O' => 'Let\'s Encrypt', 'SSL_SERVER_I_DN_C' => 'US', 'SSL_SERVER_S_DN_CN' => 'u.padilla.net', 'SSL_TLS_SNI' => 'u.padilla.net', 'HTTPS' => 'on', 'H2_STREAM_TAG' => ‘xxx', 'H2_STREAM_ID' => '1', 'H2_PUSHED_ON' => '', 'H2_PUSHED' => '', 'H2_PUSH' => 'on', 'H2PUSH' => 'on', 'HTTP2' => 'on', 'SCRIPT_URI' => 'https://u.padilla.net/p/index.php', 'SCRIPT_URL' => '/p/index.php', 'FCGI_ROLE' => 'RESPONDER', 'PHP_SELF' => '/p/index.php', 'REQUEST_TIME_FLOAT' => 1539599734.388563, 'REQUEST_TIME' => 1539599734, )

On 9 Oct 2018, at 22:36, Thomas Steur <notifications@github.com> wrote:

Sorry meant 3.6.0, 3.6.1 isn't out yet :)

Two things: I'm just seeing the fix will only apply if you delete your current stored Matomo URL. Any chance you can execute this SQL query and check if the error persists?

delete from piwik_option where optionname = 'piwikUrl';
Your table prefix may differ from piwik
.

If it then still uses the wrong URL, and in case you are familiar with PHP/Server could you maybe just for one request apply this file change send us the output of this (make sure to remove the added lines after testing):

diff --git a/core/SettingsPiwik.php b/core/SettingsPiwik.php

index bfd4ab4aeb..616a98cd01 100644

--- a/core/SettingsPiwik.php
+++ b/core/SettingsPiwik.php
@@ -177,6 +177,12 @@
class SettingsPiwik
*/
public static function getPiwikUrl()
{

  • $currentUrl = Common::sanitizeInputValue(Url::getCurrentUrlWithoutFileName());
  • $test = Url::getHostFromUrl($currentUrl);
  • var_export('host: ' . $test);
  • var_export($_SERVER);
  • exit;
  •  $url = Option::get(self::OPTION_PIWIK_URL);
    
     $isPiwikCoreDispatching = defined('PIWIK_ENABLE_DISPATCH') && PIWIK_ENABLE_DISPATCH;

@@ -189,8 +195,6 @@
class SettingsPiwik
return $url;
}

  • $currentUrl = Common::sanitizeInputValue(Url::getCurrentUrlWithoutFileName());
  •  // when script is called from /misc/cron/archive.php, Piwik URL is /index.php
     $currentUrl = str_replace("/misc/cron", "", $currentUrl);


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@tsteur commented on October 15th 2018 Member

I can't really explain how it would work through the web interface but not when the task is executed. As CLI should not use a different URL so it seems the tasks must be triggered through some HTTP request when executing a tracking request or so.

I reckon it will be good to also not modify the piwik url in tracker mode here: https://github.com/matomo-org/matomo/blob/3.6.1-rc1/core/SettingsPiwik.php#L183-L190 As tracking requests might be sent to a different servers for example. But this could maybe mess up with some scheduled tasks if for some reason the piwik URL wouldn't be set.

@LLPP65 could you go to "Administration => General Settings" and check if browser archiving is enabled or disabled? Also do you know if archiving is maybe triggered through a cronjob or maybe to a request to misc/user/archive.php?

@tsteur commented on November 6th 2018 Member

Any update here @LLPP65 ?

Powered by GitHub Issue Mirror