Hello, is there really NOBODY who can help here? This forum seem pretty dead to me, what's up , concrete5? Do I have to worry that you will give up?

Hello my guess is that's normal browser behaviour. This is how it works:
You are on an http page and you navigate to your https page.
On that page you have links. Those links don't have absolute URLs, starting with the domain name. They have relative URLs (eg /directory/page/... and nothttp://mysite.com/directory/page/...)...

When you click on one of those links, the browser has to interpret the URL. It understands what the domain name is and that it needs to add it to the relative URL to make it work.

BUT since the page starts with https:// instead of http://, the browser figures that's what the domain is supposed to look like and it starts using https.

Nothing to do with Concrete5 and frankly, as far as I know, nothing to be worried about.

Now, on a different topic, you can totally feel free to have a look at other posts in this forum and you will be quickly convinced that it is far from dead. But sometimes, people are busy, or nobody is sure of a solution or understands the problem. And we're all volunteers who like to share and help for the good of it.

And sometimes, because the forum is extremely active, a new topic gets quickly buried and doesn't get attention. In that case, the best way is to add a comment to bump it up on top of the list. Like you did. Except maybe, nicer if at all possible?

As for giving up, not a chance. Those are some of the most exciting times for Concrete5.

Anyway, I hope you better luck next time. I am sure you will soon find that we're a good community with good respectful people. And you'll always be welcome.

Take care

Thank you so much! That really helps, an I am very happy to find concrete5 alive. I have chosen it among a long list of cms, because I think it is just the best.

Now, with your explanation, which is perfect, the problem narrows a lot

I will seach for relative an broken links on my https page.

Thanks again an best regards,

Ax

If I may make a comment and give you a suggestion: relative URLs in links are normal, nothing broken here. It is also a plus in many situations. For example, imagine changing your domain name or directory in which your website is, relative URLs will still work.

Now my suggestion is to make your whole website SSL protected. First for your peace of mind, and second if Google ranking is important to you. Google has been pushing for more security online and has stated that, eventually, more secure sites will rank higher than others.

Like that, you don't need to worry about whether this page should be protected or not and you are trully protected.

No this does happen, it is bizarre and it's a problem. The same thing has been happening on our site, and it's confusing visitors as we don't have SSL (no need, it's an information-only site and doesn't handle credit cards) so they get a self-signed certificate error.

The autonav block for example generates absolute links, and occasionally just all of a sudden for no apparent reason they all come out HTTPS. I've seen it happen (once every few days) and had the "why's the website not working, it's saying some scary things about security?" calls. It can be resolved temporarily by erasing the site cache, but re-occurs later.

Do we have anything in common? Theme based on Bootstrap3 implemented using the theming tutorials. Addon javascripts: captionjs, picturefill, redactor image autoheight, ReView (desktop link support), qtip. smartsupp for live chat. However, I can't imagine why anything client-side would be causing problems that get saved to the site cache.

Thank you I am glad to find someone who has the same problem. I stopped following it for a while, because I had no time. Mnakalay conviced me, but shortly afterwards I realizded his answer was ignorant, because I alread had described that the issuse solves with cache clearing, which could not be the case if it wasn't a concrete5 issue.

I think it's only autonav which causes the problem - maybe a code correction of the autonav block could be a workaround - does anybody have an idea?

Looking at the block controller and then tracing it back through c5's code, it seems to go like this
Controller uses getURL from nav_item.php
getURL relies on DIR_REL which is defined in bootstrap/start.php and refers to $cms['app_relative_path']
app_relative_path is defined in src/Application/Application.php and gets itself from a trimmed $home variable
$home in the same file is created from the SCRIPT_NAME php variable.

This seems to suggest that SCRIPT_NAME is containing https at some point.

Couple of possibilities I can think of:
1) Something weird going on with Plesk (if we're both running Plesk based servers that'll start ringing a few alarm bells)
2) Maybe a repeat visitor using a browser extension like HTTPS Anywhere and happening to catch the site just as the cache expires (that timing though)

Other than that I'm at a bit of a loss and might have to try and redirect https to http via .htaccess or something. But that does feel like a bit like masking a problem instead of solving it. (and am concerned it might cause an infinite loop somewhere)

Looks like concrete5 could need some improvements in "debugability".
Anyway, $_SERVER["SCRIPT_NAME"] returns a file path, not an URL, so there is no protocol prefix. It is documented like this and a quick check reveals that this is true.

My mistake, I had a very brief Google of the variable but couldn't find much about it. It's probably a case of having a good read through the code and trying to figure out what's going on. c5 while being very user-friendly for the end user out of the box, is very much a CMS 'for developers' if you want to go beyond the basics.

Ah yes forgot to mention that - I knew what you meant by your use of the word ignorant which is technically correct in strict dictionary terms (as in lacking the full understanding of the problem) but it's so frequently used as an insult that it's generally taken as one if directed at an individual and has its own colloquial meanings similar to 'rude' or 'arrogant'. It's best used sparingly and qualified with "of the facts relating to {subject}". I don't envy anyone trying to learn the English language when even the dictionary can be a questionable source. At least it makes learning c5 look a little bit easier :)

"Mnakalay conviced me, but shortly afterwards I realizded his answer was ignorant"

Really? First you complain nobody is answering you, I give you an answer based on experience. You even thanked me for it. An now you are calling me (or my answer, same difference) and ignorant?

That's really uncalled for.

Since I'm an ignorant and you, obvisouly, are not. I suppose I don't need to tell you you're loading jquery twice, 2 different versions, on your home page?

Nothing to do with your problem. Just showing my ignorance.

Hello,

Thank you for taking care. It didn't want to insult you, it's a problem of language mastering. I ment "ignorant (=not knowing) the detail that the problem removes itself by cache clearing". I wasn't aware that the word has a much general meaning.

Regards,

axelbenz

P.S. the second jquery came with version 5.7, obviously the import of the first version was done incorrectly.

-----Ursprüngliche Nachricht-----
Von: concrete5 Community [mailto:discussions@concretecms.com]
Gesendet: Donnerstag, 9. Juni 2016 13:48
An: abenz@almodovarhotel.de
Betreff: Links strangely switch to https in 5.7.5.6 : 5.7 Discussion

Gave up and got an SSL certificate, but when implementing it, it becomes more obvious why this happens. It's the block cache. If someone happens to request the site as HTTPS (guessing one of our visitors has HTTPS Anywhere installed) just after the default 6 hour cache purge, the blocks are generated with HTTPS links. (Good behaviour if you're on HTTPS as then the links around the site don't take you back to insecure mode). This is then stored in the cache.

Really if the software is going to generate absolute URLs it should just use the format "//example.com" rather than generating "https://example.com" or "http://example.com" based on what it detects.

You can work around it by disabling the block cache, if your server is fast enough that it doesn't impact performance.
Edit: Also turn off full page caching.

Good detective work! It would be good if you'd submit a bug report for this. It's pretty important and is impacting on quite a few sites.

It's hard to be certain about the exact cause, but have opened a bug based on the symptom explaining the *suspected* cause herehttps://github.com/concrete5/concrete5/issues/3969...

I think this is one of those cases where if you have an SSL certificate on your site, you really should just use it for all requests and prevent/redirect non-https requests all together.

It's a very similar problem to if you have parked domains on a website. You can set things up on a host where two different domains point at the same website, but you shouldn't allow visitors to _navigate_ the site through two different domain - auxiliary domains should redirect to the one main domain. You'd have the same problem cached urls without a redirect in place I believe.

On the sites where we've installed ssl certs we've simply dropped in a few lines into the htaccess file to force all requests to https. Doing it this way we don't ever have to think about clearing caches or protocol-relative urls, concrete5 just always returns the site over https://. We don't play around with the Canonical URLs section within the Dashboard either, we leave those values blank.

This also helps tell Google to use the https version for indexing.

Sometimes you see sites where the main content is http and then a checkout page is switched over to https - I can't really think of any advantage to this, if the SSL cert is there you might as well use it for all content. It probably makes the checkout pages a little _slower_ initially, as it would have to re-download the site's scripts and css over the different protocol.

For reference our htaccess files tend to look like this on a site where we're forcing https and the www:

In an ideal world I agree (and especially so do Google, EFF etc)

A problem arises however in situations like ours where a third party resource is required and that resource is hosted on a site that doesn't have SSL. These will be blocked, with a warning in the browser about unsecure elements - or if including with https or protocol relative URLs the browser will tend to just see an invalid self-signed certificate and silently discard the resource.

In our case it's a tracker called Lead Forensics. I realise this product has some glaring privacy concerns of its own (though it remains legal by only reporting on businesses) and that ideal options are "don't use this" or "pick an alternative that supports SSL" but sometimes things like this are mandated by marketing/management teams outside of the web developer's control. It can't be rehosted as it relies on requests to their server. But this is just one example.

I'm not going to force the site to HTTP if HTTPS is detected (which doesn't help with any certificate issues as the request has to be made via HTTPS before the redirect kicks in) as that would be taking it too far, but conversely forcing HTTPS would quickly get me complaints about lack of visitor data..

Totally understand the issue with third party stuff, marketing, etc.

But why is forcing http to be used taking it too far?

If you don't have an SSL cert installed (or the environment is invalid due to mixed security), you're not then actually supporting the site via https. If you aren't support https, I don't think you should even allow requests to complete via that protocol - it would make sense to force the protocol your site actually supports.

Sorry that was more of a personal opinion based on that we do now have an SSL cert ourselves. I'd rather that if a visitor prefers HTTPS, they don't get forced down to HTTP (even if that breaks tracking)

Will reiterate though, any original request made via HTTPS will still have to go through a certificate warning before it actually touches the .htaccess file. This isn't something c5 has control over, and hopefully it'd prevent the wrong version being cached, but is a point to bear in mind.

If someone tries to access the site via https and they are getting warnings about invalid certificates or mixed protocols, then I'd argue you are _aren't_ actually serving the site through https. I see it that if you can't provide https 100%, then you shouldn't even allow it to be used.

If I was in this position, I'd be:
- Forcing http
- Answering any questions about 'why aren't we using https?' with 'we cant because of the third party script, ya dingus'
- Potentially asking the third party provider to add an SSL cert.. I mean, geez, it's 2016! :-)

I believe any htaccess redirect would happen before concrete5 even sees the request, so they'd be no generation of the page and no caching.

Hi,

well - Just believe me, there are reasons to use mixed http / https pages on a site. Even in 2016.

"If I was in this position, I'd be:
- Forcing http"

That's what I try to do - for most of the pages. But concret5 prevents me from doing so.

"- Answering any questions about 'why aren't we using https?' with 'we cant because of the third party script, ya dingus'"

There are no questions - customers just stay away.

"- Potentially asking the third party provider to add an SSL cert.. I mean, geez, it's 2016! :-)"

We have one. Our provider allows just one. We need in on several places. And so on. As I said: There ARE reasons.

"I believe any htaccess redirect would happen before concrete5 even sees the request, so they'd be no generation of the page and no caching."

And there are of course reasons to use https on some pages.

It's clearly a concrete5 bug, so we should focus on the bug, not on the way, the bug reveals itself.

@derykmarl, @mesuva couldn't a proxy be used to load the insecure assets or call the insecure service?

This article explains a few ways of doing so:https://www.perpetual-beta.org/weblog/mixing-secured-and-unsecured-a...

Interesting idea, though I don't think it'd help in our particular case as the tracker would then be tracking the proxy instead of the end user.

Tend to agree that the ideal solution is to bug Lead Forensics into investing in an SSL certificate. Even a basic one meant for individuals will do.

No, the ideal solution is a more intelligent concrete5 block cache. There is absolutey no need to cache the protocol part of an internal url.