in front of the URL string (e..g, during the definition of "u").
Is there a reason for this?
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
For more information: https://en.wikipedia.org/wiki/Uniform_resource_locator#Protocol-relative_URLs
Thanks for clarification! First it did not work on my site but now it interestingly does.
See #7267 where we talked about a similar thing. We're getting this feedback quite often recently. :+1: for this
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)
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
Also maybe interesting read The Protocol-relative URL technique is now an anti-pattern
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
Provide to separate options to
forse_ssl. First for UI(i mean when the user login into piwik admin page), second for tracker.
As part of this issue we should also check this FAQ:
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.
See also: Google Analytics uses HSTS - maybe we could send this response header HSTS? https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
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
HSTS would solve this (at least after the first request), but it also should work without it.
@tsteur That's great.
Maybe also suggest enabling
force_ssl=1 and the ForceSSL while installing if the site is using HTTPS.
The plugin sets "force_ssl" automatically
@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.
See https://github.com/piwik/piwik/issues/7366#issuecomment-77496199 it should be still forced in Piwik as well eventually IMO.
@tsteur, what comment do you mean? The link just links to this issue.
That's funny, link seems to not work. Meant my second comment.
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.
This issue is only about changing
var u="//<url>"; to
var u="https://<url>"; in the JS tracking code when force_ssl is enabled
In my opinion this change is required regarding GDPR as we can't protect user data data properly if we don't even know who read it before it hit the Matomo server.
I would even go as far and send a reminder to users to update their old tracking codes.