- changed component to SMF
-
assigned issue to
- edited description
Submitter: alberthrocks
Priority: Medium
Location: Forum
Issue: HTTPS works, but it does NOT seem to be default. Links on the forum drop the HTTPS immediately. The forum should be configured to use whatever protocol the user is using. (e.g. if the user is using HTTP, use HTTP links; HTTPS, HTTPS links)
Also, if you want to, you can also promote SSL by indicating SSL availability when using HTTP. (Maybe a small little bar saying that SSL is available?)
Comments (9)
-
reporter -
Looks like it is fixed! It looks like you guys are using Cloudflare SSL (woo), and all links seem to be forcing HTTPS, which is nice! (This is especially good with unsecured WiFi connections, which transmit any private data in the clear...)
The only minor complaint is that you can still access http://www.omnimaga.org/index.php (non-HTTPS). Since all of the links are forcing HTTPS, maybe we can make it so that it redirects to HTTPS automatically?
Other than that, great work!
-
reporter Well we actually have letsencrypt setup, but we aren't forwarding that in the background quite yet due to still setting up all the subdomains. As for enforcing it, we do have the following rules in our .htaccess that should be doing that
RewriteCond %{HTTP_HOST} ^omnimaga\.org RewriteRule ^(.*)$ https://www.omnimaga.org/$1 [R=permanent,L]
I'm a little confused as to why it's not actually enforcing https.
-
reporter @alberthdev While you can still forcefully hit the http site, I don't think it's big enough of a deal to keep this issue open since any link you hit from there will enforce ssl. May I close this issue?
-
Don't think it's too big of a deal - I just tested and verified that all links go to HTTPS. The only functionality that might be iffy is logging in, which doesn't work on HTTP (due to security enforcement for HTTPS), but that's it. Assuming all links and resources (CSS, scripts, images, etc.) are HTTPS, users should have no worries about leaking their cookies in unsecure networks (hopefully)...
If you happen to be using NGINX on the server side of things, I have a snippet that I can post here if you want to enforce the HTTPS redirect.
-
reporter @alberthdev Enforcing https on login is a feature ;P
We are using Apache and switching over would be a lot of work unfortunately. I've already posted above my rules that I'm using.
-
reporter - changed status to resolved
-
Notifying the user that the login will fail miserably should be a feature too... :P Though I guess a really dirty solution would be to embed some JS to hide the login box and replace it with a "To login, click here to switch to HTTPS" or something silly...
Yeah, no worries about switching over - just curious!
As a last ditch attempt: assuming
RewriteEngine On
(almost certain that this is the case, otherwise you'd notice other problems...), maybe addRewriteCond %{SERVER_PORT} 80
? (And as a last last ditch attempt, possibly adding[NC]
to theHTTP_HOST
match?)EDIT: Also, possibly the rule is being superseded by another terminating rule above? (e.g.
[L]
attached to another rule above that is getting triggered) -
reporter @alberthdev I think you should create a new issue about the failure to login via http and assign it to Sorunome. He's done a bunch of work on the login process to secure it more and so this really falls under something he needs to look into.
Checking ports wont help as we are using cloudflare to connect, so the port that Apache thinks you are connecting on will always be the same. We could potentially add a script that enforces it on the client side, but I don't know if it's that important. As for another rule overriding, the https rewrite is the first rule in the file. https://bitbucket.org/omnimaga/omnimaga.org/src/c79cb07be38dda1d200c4933f2545ec8ca9984c9/.htaccess?at=master&fileviewer=file-view-default#.htaccess-5:7
- Log in to comment
Should be fixed now @alberthdev might looking into it?