Advertisement:

Author Topic: SS!/https version of repair_settings.php ?  (Read 19495 times)

Offline richardwbb

  • Jr. Member
  • **
  • Posts: 314
  • currently reading; '$smcFunc'
Re: SS!/https version of repair_settings.php ?
« Reply #20 on: February 24, 2017, 05:16:34 PM »
I wonder, Illori, is there a way to make any browser to 'try' https, with every possible [http] link the forum software encounters, [I'm aware of performance penalty, that isn't why I am asking you, but this has my interest too], then, on a 404 or port closed, try http, to probably succeed or to confirm it indeed seems to be a 404.

I am using https now, with the help of Let's Encrypt and aegersz, but, as I learned from someone's code, putting '//domain.tld' makes a browser go with http, or, https, based on what protocol is matter of course. But, making the forum software, change; 'http' to; 'https', [I'm not aware how, but I am able to change all 'http' in a MySQL dump to https], will result in a 404 for providers that do not have ssl enabled.

Can you shed some light on this, since, I've learned that *some* modifications, [that are really, and I mean, really, competent], are surpassed by time, since they contain 'http://domain.tld' coding, while '//domain.tld' works cross-browser, and it makes 'http', or 'https', preferable, as the matter of course.

it should be uploaded as far as i know but you should wait until 2.0.14 unless you want all your images users may embed in posts to cause issues.
If my post in this topic looks ambiguous to you, then I'm with Murphy's law and General Stupidity. In other words, trial and error.

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 71,861
    • StoryBB/StoryBB on GitHub
Re: SS!/https version of repair_settings.php ?
« Reply #21 on: February 24, 2017, 06:01:52 PM »
HTTPS Everywhere would be the solution for that, but there's still large amounts of the web that do not do HTTPS - and you'd be surprised that not everywhere actually *needs* it because browsers aren't going to list pages as insecure unless they have a form on them with a password and no HTTPS.

This site, for example, does not list 'insecure' for me even in current Chrome, while I'm logged in.

Forcing all links to go in this fashion is not actually particularly clever in the scheme of things because until they actually go HTTPS their end, you can end up with a poor experience depending on various things. I've even see cases where you go to https://example.com/ and end up getting a completely different site because of misconfiguration of Apache and the fact both sites are hosted on the same server.

As sites migrate to HTTPS, they'll also start putting in redirects - and the smart ones will use HSTS anyway so the browser can be told 'don't bother trying HTTP, for the next x days, just assume I want you to use HTTPS' and they'll automatically do it without even having to have a server roundtrip.
Don’t try to tell me that some power can corrupt a person. You haven’t had enough to know what it’s like.

No good deed goes unpunished / No act of charity goes unresented.

Offline richardwbb

  • Jr. Member
  • **
  • Posts: 314
  • currently reading; '$smcFunc'
Re: SS!/https version of repair_settings.php ?
« Reply #22 on: February 24, 2017, 08:30:54 PM »
Hey Arantor. If you are reading this, you might want to skip over to the code and just read everything beneath. [or just forget about my point I try to make, I won't mind, since I am confident [by reading this forum for quite some hours], that SMF won't fail on its community].

I value your words. I noticed you have spoken from a client perspective and I noticed with that, I didn't take this in consideration. Also, now I've read a little about HSTS, I noticed that it protects one of 'cookie hijacking', since I read somewhere; 'In computer science, session hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session'. With 'valid computer session', I find it safe to assume that SMF will take that in consideration over my personal preference, and, in that case, I will wait patiently.

For HTTPS everywhere, I'm a sincere user of Mozilla Firefox. Of course I am running Chrome [As a developer I need it], but, their way of storing settings I just won't get used to and it might just be me, but I'm just not willing to install a modification for a big browser brand, to let me choose which url to connect with, 'open new tab'. I find their way of sovling this, both, genius [eighty percent or more of all internet servers prefer Chrome], and obstructing [I find that; Mozilla Firefox is like Apache is to Nginx]. Most users will prefer Chrome over Firefox, and forgive my ranting, the Firefox developer tool I understand, and that I found hard enough.

I wasn't aware it isn't wise to force all links in this fashion, as you have written. I understand from investigating on a single forum I am Site Admin of, and that is not similar to the broader situation you have spoken of, of course. The point was, users post links to images, hosted by another 'cdn' or 'myalbum', 'imgur'. Now, some of those hosts, support https, and some just don't or are totally free and ask for this particular case, a small fee. 

However, I am not able to refine of your words, what exactly has been running your mind. I've learned that, Firefox, since version fourtyseven [and possibly even older], until now, is dropping javascript that is comming from 'http'. And, after noticing, that *something*, isn't 'https', it starts notifying the user, that; 'there might be a picture that has been altered since it wasn't a secure connection', which made me laugh, but I also understand that of all surfers of the internet, a lot of them aren't paying attention to security, no matter if they are able to understand what this is or not.

Now, my Mozilla Firefox, and Google Chrome browser is running in my native language, [so I'm not able to quote the exactly] but I find it awkward, that, Firefox is, very, very protective, to their users, and Chrome is closer to notifying the user that;' 'the domain the user went to. meaning; the forum I care for, meaning; what is important to me', is secure, but, 'there are sources on it that are not secured', meaning there is a javascript or jpg that is called for over http.

Now, the latter, is working quite well and for Mozilla Firefox, no matter what, I've had to use pretty urls 'updateSettings(array('pretty_root_url' => $boardurl)', to tell it to use https [to everyone; this isn't SMF related], and, to use 'repair_settings.php' and change all those 'http' to 'https', and finally; there is only *one* way I found that is working [since php isn't always reporting '$_SERVER["HTTPS"]' by var_dump, or even still saying 'port 80', while it really is 'port 443'. That I had to use [to make SMF and Firefox agree to redirect all http redirects to https [this means; Mozilla Firefox, detected http, dropping to http, and; htaccess redirecting to https, meaning; http isn't supported any longer at all]; If that wasn't clear, the darn thing keeps dropping to http and htaccess keeps kicking it to https and that is just Mozilla Firefox, meaning, any browser could behave like this and I wasn't able to achieve this behaviour [which is preffered, what is the maximum that is possible, to open every page that holds *no* http query, and show a 'green and secure logo', without notification of something, very, very, small, to all the users in the whole world, I spoke with peope close to me, they usually don't know what I'm asking when I say 'secure web page']. and this has to be solved with htaccess. Since browsers won't default to https, but always will prefer http first [think about it, the whole world we live in receives the news we should use https, well, this is what happening in the way, the Mozilla and the Chrome, can't be blamed, they are blaming the administrators, meaning, you.]

Code: [Select]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# RewriteCond %{HTTPS} !=on
# RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

I understand that this is a long story [again, sry], but please be notified, Mozilla Firefox, keeps dropping https to http, and this code has helped me. [I'm not getting this since I assume that SMF forum software running 'https', can not fall back. It did this with Chrome, another browser so unknown I won't mention it, and Mozilla Firefox 51, kept dropping to 'http', since it was available [my ISP won't allow me to close port 80, which I won't blame them for], when; a single picture, or javascript was called over http.

And for a forum, an image inclusion over http, can not be changed to a mandatory https query, since the remote host might not support this, and that would obstruct regular users that make me happy since they are *able* to post an image, make pull their hair out on a security issue, which doesn't interest them and which I believe shouldn't be bothering them.

For the long post; I noticed that Mozilla Firefox holds a different view and Chrome is more forgiving on this, Mozilla Firefox users are scared a bit I find, and Chrome is to the point. In the end, without a redirect by htaccess, I couldn't get Mozilla Firefox to drop javascript [meaning that Fancybox seized working], and Chrome would take this. I wonder if there is anyone that has written a standard for this, and if so, if Mozilla Firefox and Google Chrome had a different way of interpreting.

Finally, for the people that made it up to here in my post; it would be a lot easier, if browsers preferred https over http, then keep notifying users that usually don't even know the word 'security', or 'https', then giving administrators an headache overcoming this. This I find uphill behaviour, Google Chrome and Mozilla Firefox, can't be blamed [take my word for it, their preferal of https over http will give them problems], and they put my administrator life in to misery, which I have no respect for at all.

p.s. I couldn't learn why the code that has been '#', won't work for Mozilla Firefox, while the code just above does. Also, be aware, I'm being a bit fundamental here, there are easier ways to solve every issue anyone might run in to, I'm just after, a fix once, and support every 'silly' combination internet surfers come up with, [don't forget the mobile phone with it's native browser, which isn't Firefox or Chrome], since I believe they [the casual internet surfer] *can* be unaware, and therefore, are perfectly able to do so. And another one, anyone getting this, it just makes no sense to contact Mozilla Firefox for this and explain to them this is a reason out of many I am aware of, why they currently losing marketshare to Google Chrome [which I find isn't the liberty, people deserved in the first place with the internet, open source and such]. A final word, don't ask me about EU Cookie Law. It will be a long post. ;)
If my post in this topic looks ambiguous to you, then I'm with Murphy's law and General Stupidity. In other words, trial and error.

Offline Jailer

  • Jr. Member
  • **
  • Posts: 142
  • Gender: Male
    • Bored Guy Blog
Re: SS!/https version of repair_settings.php ?
« Reply #23 on: February 24, 2017, 09:27:53 PM »
Do a 301 redirect in your server config and be done with it. It really is as simple as that.

Once you've got that working then you can enable HSTS and your visitors will all be connecting via https after their first visit.

Offline Arantor

  • Resident Overthinker
  • SMF Friend
  • SMF Legend
  • *
  • Posts: 71,861
    • StoryBB/StoryBB on GitHub
Re: SS!/https version of repair_settings.php ?
« Reply #24 on: February 25, 2017, 04:45:32 AM »
Quote
until now, is dropping javascript that is comming from 'http'

If the JS is coming from HTTP but the overall site is HTTPS, there's your problem - mixed content is considered insecure and JS from HTTP will not be run on an HTTPS site on the presumption that HTTPS is considered more secure. A 301 or ensuring all paths are correct will fix that for your site, but you can't fix other peoples' sites.

To fix the images-over-HTTP problem, the solution isn't to sit and have some kind of rewrite, but to proxy the image. 2.1 already supports this, I believe it's being backported to 2.0.14 but don't quote me on that - it means the server makes the HTTP request and serves the content to your user over HTTPS without them having to do anything.

The 'falling back to HTTP' issue sounds like something wasn't configured to use HTTPS, perhaps the forum, perhaps theme paths, not sure what without seeing the URL in question.

The problem with browsers 'preferring' one content scheme over another is largely a historical matter when certificates used to be expensive and hard to set up (and in some cases actually problematic to set up before things like SNI came along), plus the fact that for a long time the additional processing cost of the encryption made it only worthwhile for sensitive matters, but Moore's Law has largely fixed that over the last 20 years or so.

As for FF losing market share to Chrome, there are several reasons. Their hardline stance on ideology (cf. things like not supporting h.264 out of the box) is admirable but the reality is that users don't care. Users see videos not playing in the browser, assume the browser can't do it, not that the browser makers chose for it not to by default. Then you have the attempt at diversification into areas no-one cared about (Firefox OS), you have the various ways they've built up and subsequently removed plugin features (XPCOM and XUL, meaning that programmers largely had to rewrite, or ditch, their plugins)

Plus you have the technical issues; FF leaks memory more than Chrome does, it's frequently slower than Chrome and suddenly people find that whatever ideological merits Mozilla has, they still have stuff they want to do, whether it's work or watching cat videos on YouTube.
Don’t try to tell me that some power can corrupt a person. You haven’t had enough to know what it’s like.

No good deed goes unpunished / No act of charity goes unresented.

Offline richardwbb

  • Jr. Member
  • **
  • Posts: 314
  • currently reading; '$smcFunc'
Re: SS!/https version of repair_settings.php ?
« Reply #25 on: April 04, 2017, 02:49:21 PM »
I've made;

.htaccess;
Code: [Select]
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

and used a modified version of repair_settings.php, which 'aegesrz' gave to me. It wouldn't be hard to create your own either.

It is a while ago, but I believe I had to do more, it where three steps, not two, for Firefox. Some hard used browsers did swear up too. But Firefox is a good browser and Chrome no different, my opinion is biased and that I'm used to Firefox. Some sites offer the apple version, [Safari I believe], Chrome and IE. :/

Ah, I remember now, te HSTS, with the 'Strict-Transport-Security: max-age=31536000', not remembering but that was Arantor's point and I'm using it now. I didn't take that max age variable serious, for the code and what it does, I believe a on/off construction would have be more enlighting to me.

Now I wonder if there is a way to tell simplemachines by index.template.php or somewhere else, that I supply a list of valid https content hosters, which there are and considering to change signatured of people since it can be https link existing, but the user didn't use it which I won't blame them for of course.

And another quick tip, instead of changing any hard coded http://domain.tld, use //domain.tld, browsers stick with the 80 or the 443 they are on. It fixed my version of FancyBox 4 SMF, it's going http:// hard coded on two places in the code. Firefox drops it and it says '00' somewhere in the generated by php, html code. Chrome runs it. It is a good mod, I've mailed the guy with the panda a fan-mail but didn't hear from him, which I regret.
If my post in this topic looks ambiguous to you, then I'm with Murphy's law and General Stupidity. In other words, trial and error.