Hi @mtandersson thanks for the report

let's investigate this issue as part of the broader set of bugs in #6880 -> our goal will be to make Piwik work perfectly in this special use case which many users have reported issues with.

This might be easier to fix than all the other referenced issues in #6880 just FYI. So not sure if it is worth waiting

@tsteur When we will have resolve for this issue ?

It's not scheduled so it may take a couple of months. @mattab as it might be easier to fix than the others and as it is a bug that makes it impossible to use with HTTPS (maybe even a regression), maybe it is worth to schedule it a bit earlier but not sure.

@mtandersson can you let us know the content of PHP $_SERVER? We kinda need it in order to fix this issue.

To get it, can you create a file like test.php in your Piwik directory and paste

<?php

var_export($_SERVER);

afterwards you can open this file by opening the URL https://yourdomain/test.php in the browser. Please remove this file afterwards again

Hello! Please tell me when problem with real map will resolve ? I have the similar problem #8239 and i want to know about this.

@simpleuser99 to solve this issue we need your help see the comment above. Would be nice if you could send us the output of that test.php

@tsteur

@simpleuser99 do you mind adding this line https://github.com/piwik/piwik/pull/9099/files#diff-a1ef1fb37277203311f5eed60b826653R119 to core/IP.php and see if it changes something for you?

If not, do you mind copy/pasting the actual content of this into this issue? Feel free to anonymize the parts you blacked out. To test it, we need the IP information though that you also blacked out. Here's an idea: Say there is an IP please replace all occurrences of the same IP with any random IP say 111.111.111.111. If there's another IP replace all occurrences with another IP say 111.111.111.112. This will be needed for us to reproduce it.

@tsteur I adding line 119 (return '';) to my core/IP.php, but I don't see any changes in piwik web interface.
I attached new test.php screenshot according to your request

I remind you, my problem is #8239

Thx! I reckon we could check for the $_SERVER['HTTP_UPGRADE_INSECURE_REQUESTS'] = 1 and maybe assume it is HTTPS. (see eg http://stackoverflow.com/questions/31950470/what-is-the-upgrade-insecure-requests-http-header and http://www.w3.org/TR/upgrade-insecure-requests/ and http://www.w3.org/TR/upgrade-insecure-requests/#examples ) but from what I understand it doesn't necessarily mean HTTPS is actually used. The HTTP_X_FORWARDED_PROTO entry is missing here. Not sure if it is a server side misconfiguration on the load balancer or so (it seems like HTTPS is terminated on the load balancer). Not finding too much information re HTTP_UPGRADE_INSECURE_REQUESTS.

We were just talking about detecting a misconfigured system (Piwik server side says HTTPS is not used but JavaScript detects HTTPS) and then letting a user know how to fix it (assume_secure_protocol=1).

As we can't fix all the cases this might be the way to go

We were just talking about detecting a misconfigured system (Piwik server side says HTTPS is not used but JavaScript detects HTTPS) and then letting a user know how to fix it

Created issue: When the page is loaded over HTTPS but Piwik thinks it is loaded over HTTP, explain in a notification how to solve issue #9145

I reckon we could check for the $_SERVER['HTTP_UPGRADE_INSECURE_REQUESTS'] = 1 and maybe assume it is HTTPS.

we just tested and found that Chrome seems to always set 'HTTP_UPGRADE_INSECURE_REQUESTS' => '1', in requests, even on http, so we cannot use this request header flag.

This issue will be fixed with the new notification in #9145 explaining to users the "workaround". after internal discussions we couldn't find a better way to solve this issue.

I will close this one as we have #9145 for it (and a PR is already issued for it)