Works for me, force_ssl_login is for login form only and force_ssl is for all pages.
For the Overlay+SSL bug see #3691
My global.inc.php has force_ssl_login = 1 and force_ssl = 0.
Try for yourself:
http://geekbox.me/piwik (should redirect to SSL)
user = piwik
pass = piwik123
Notice how after logging in, it doesn't go back to non-SSL.
I can reproduce that force_ssl_login=1 will also redirect non Login URLs to SSL.
I'm also affected by the overlay issue described in #3691, and the combination of force_ssl and force_ssl_login would somehow solve the issue for me (so that only the login screen is ssl). But as this bug report describes, this is not the case.
I'm confused with the last comment of matt: although you say you can reproduce the issue, you've closed the report and set the resolution to worksforme. Isn't this a contradiction?
It was a misclick, thanks for pointing it out!
sorry for going off topic: there seems to be no way to subscribe to a ticket under this trac installation. I can't change the cc field
Updated spec for this ticket to clarify what does not work:
if I set force_ssl_login to 1, and force_ssl to 0, then the login will be secure, but after login user should be redirected to HTTP. Unfortunately, once I log in, the site remains in SSL mode.
it's hard to make force_ssl_login work as described here. Instead I will completely remove the force_ssl_login setting from the settings. Please only use force_ssl from now on. One reason we don't like force_ssl_login is that the auth cookie would have to sent over http which is not secure. So this setting has no extra value compared to force_ssl.
If there are other bugs in piwik with force_ssl then please post on the related ticket or create new bug reports if not there already.
In d1684719f1d494e9b1a2d686b5da0e4164f11340: Fixes #4001 Deprecate force_ssl_login setting as it's too hard to properly enforce
I understand the difficulty and why you remove the option. But please put a note in the faq that with this option site overlays won't work on non SSL sites.
Ok that sounds like a good improvement: in case the website does not load in HTTPS, we default it to HTTP. Or maybe we always use website over HTTP for overlay report?
Since it already opens in a new window, we can simply open that new window over HTTP ?
We have to deal with the cookie set which is set with "secure" flag right now... not sure what the solution is to have authentication work on HTTP with the cookie on HTTPS...