@b-pfl opened this Issue on March 5th 2015

Dear all,

I just noted that the auto-generate javascript / image tracking code seems to be incomplete for the server URL. The following code is generated and misses the protocol information (e.g., "https:" or http:"
in front of the URL string (e..g, during the definition of "u").

Is there a reason for this?

<!-- Piwik -->
<script type="text/javascript">
  var _paq = _paq || [];
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="//<url>";
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', 1]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  })();
</script>
<noscript><p><img src="//<url>?idsite=1" style="border:0;" alt="" /></p></noscript>
<!-- End Piwik Code -->
@sgiehl commented on March 5th 2015 Member

Sure. This URL is missing the protocol to let the browser decide which
protocol to use, based on the website the tracking code is on.

That way the tracking pixel will always use the same protocol as the
tracked website.

@pebosi commented on March 5th 2015 Contributor
@b-pfl commented on March 5th 2015

Thanks for clarification! First it did not work on my site but now it interestingly does.
Is there a chance to define that the autmatically generated script always links to the encrypted page? When I set force_ssl to 1 in config.ini.php requests to the web interface get redirected to https://. However, this does not affect the javascript / image code fragments generated in the backend...

@tsteur commented on March 5th 2015 Owner

See #7267 where we talked about a similar thing. We're getting this feedback quite often recently. :+1: for this

@mattab commented on March 5th 2015 Owner

I renamed issue in attempt to clarify the scope. I'm not 100% sure that we should make HTTPS tracking the default when force_ssl=1 because it could have some performance implications on Tracking API (for example we use force_ssl but we haven't tested performance implications if suddenly all tracking api requests would use HTTPS)

@tsteur commented on March 6th 2015 Owner

I think it is more about what users expect. When I set a force_ssl property to 1, then I would expect it is considered everywhere unless it is named something like force_ssl_in_ui

@tsteur commented on April 17th 2015 Owner
@mattab commented on May 15th 2015 Owner

in the forums, a user expected force_ssl to also force SSL connection to Tracking API on his websites: http://forum.piwik.org/read.php?2,126694

@Globulopolis commented on June 30th 2015 Contributor

Provide to separate options to forse_ssl. First for UI(i mean when the user login into piwik admin page), second for tracker.

@mattab commented on July 9th 2015 Owner

As part of this issue we should also check this FAQ:
http://piwik.org/faq/how-to/faq_91/#comments

This was reported in feedback:

Comment: I think this information is a bit misleading. I worried that setting force_ssl would also force redirects for the requests made by the tracking code. That's not what I want, because we're using a self signed certificate at the moment.
However turns out that's not the case.
The documentation here suggests ALL requests are redirected.

@mattab commented on April 28th 2016 Owner

See also: Google Analytics uses HSTS - maybe we could send this response header HSTS? https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

@Findus23 commented on February 14th 2017 Member

In my opinion this is quite important.
My example use case: I am hosting a website on a cheap shared hosting (so no https possible), but piwik is on an own server (so only https, force_ssl=1 and all http requests are redirected to https)
But with the default (//-URL) all visitor data is transmitted unencrypted and (because of the redirect) again via https.

As a result

  • everything is transmitted twice
  • SSL is useless as everyone can intercept the first unencrypted request

HSTS would solve this (at least after the first request), but it also should work without it.

@tsteur commented on February 14th 2017 Owner

@Findus23 I have just updated https://plugins.piwik.org/ForceSSL to also force SSL in generated tracking code.

@Findus23 commented on February 14th 2017 Member

@tsteur That's great.

Maybe also suggest enabling force_ssl=1 and the ForceSSL while installing if the site is using HTTPS.

@tsteur commented on February 14th 2017 Owner

The plugin sets "force_ssl" automatically

@Findus23 commented on May 11th 2017 Member

@tsteur, I am still not sure if adding this feature to a plugin that only few people will use, solves this issue.

Because of this the majority of users will still send the private data of their users over unencrypted HTTP even though their Piwik-Server supports SSL and as a result they think "everything is secure" even though it isn't. (And I think the the use case of having piwik on a modern server with an SSL cert, but tracking an old legacy website, which only runs via HTTP, is quite common)

It shouldn't matter how the website is delivered, the tracking data should always be sent via the most secure way possible.

@tsteur commented on May 11th 2017 Owner

See https://github.com/piwik/piwik/issues/7366#issuecomment-77496199 it should be still forced in Piwik as well eventually IMO.

@Findus23 commented on May 11th 2017 Member

@tsteur, what comment do you mean? The link just links to this issue.

@tsteur commented on May 11th 2017 Owner

That's funny, link seems to not work. Meant my second comment.

@mattab commented on December 13th 2017 Owner

Solving this issue will actually solve real bugs, so increasing priority.
eg. some servers are setup to redirect all requests from HTTP to HTTPS (even the piwik.php tracking api request). this can cause errors like Failed to load http://look.anixa.tv/piwik.php: Redirect from 'http://look.anixa.tv/piwik.php' to 'https://X/piwik.php' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://Y' is therefore not allowed access. and in some cases, this causes the session recording and possible other features to fail.

@mattab commented on December 13th 2017 Owner

This issue is only about changing var u="//<url>"; to var u="https://<url>"; in the JS tracking code when force_ssl is enabled

Powered by GitHub Issue Mirror