Force https #247

Open
opened 2019-05-13 13:29:27 +00:00 by tammoterhark · 6 comments
tammoterhark commented 2019-05-13 13:29:27 +00:00 (Migrated from github.com)

Using .htaccess:
https://serverguy.com/servers/redirect-http-to-https/

Both on live and test, so we test using the same parameters for this aspect...

Using .htaccess: https://serverguy.com/servers/redirect-http-to-https/ Both on live and test, so we test using the same parameters for this aspect...
matthijskooijman commented 2019-05-13 13:35:57 +00:00 (Migrated from github.com)

This should be optional (not all installations have https enabled). Since .htaccess is currently in git, this might not be the best place to handle this (and IIRC .htaccess does not support including a secondary ".htaccess.local" or similar). We could handle this in PHP instead with a checkbox in the settings.

It should probably only be possible to enable such a feature through a HTTPS request, to prevent locking out yourself by enabling the force HTTPS when HTTPS is not working yet. There is still the possibility of lockout when HTTPS breaks after enabling this. Perhaps the relevant settings page can be excluded from this, or people should just modify hypha.xml to recover (this requires documentation in both cases).

This should be optional (not all installations have https enabled). Since .htaccess is currently in git, this might not be the best place to handle this (and IIRC .htaccess does not support including a secondary ".htaccess.local" or similar). We could handle this in PHP instead with a checkbox in the settings. It should probably only be possible to enable such a feature through a HTTPS request, to prevent locking out yourself by enabling the force HTTPS when HTTPS is not working yet. There is still the possibility of lockout when HTTPS breaks after enabling this. Perhaps the relevant settings page can be excluded from this, or people should just modify hypha.xml to recover (this requires documentation in both cases).
tammoterhark commented 2019-05-13 13:38:07 +00:00 (Migrated from github.com)

Logging in should also be possible in the situation that you describe.

Logging in should also be possible in the situation that you describe.
tammoterhark commented 2019-05-13 13:38:46 +00:00 (Migrated from github.com)

And logging in should be really secure? Catch 22?

And logging in should be really secure? Catch 22?
matthijskooijman commented 2019-05-13 13:40:13 +00:00 (Migrated from github.com)

Good point, so excluding the settings is not a good approach. Then it would be manually editing hypha.xml to recover (or, better, fix HTTPS again).

Good point, so excluding the settings is not a good approach. Then it would be manually editing hypha.xml to recover (or, better, fix HTTPS again).
matthijskooijman commented 2020-01-20 11:02:51 +00:00 (Migrated from github.com)

One other approach would be to configure this using a special file. E.g. create a file called system/force-https or something like that, and check for that in .htaccess:

# Force HTTPS, if enabled by creating a specifically-named file:
RewriteCond %{HTTPS} off
RewriteCond system/force-https -f
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This is untested, not sure if the relative path like this will always work. Also, not sure if this file should live inside system, or maybe in the root for extra visibility (or maybe be called FORCE-HTTPS, or .FORCE-HTTPS to hide it, or...).

One other approach would be to configure this using a special file. E.g. create a file called `system/force-https` or something like that, and check for that in .htaccess: ``` # Force HTTPS, if enabled by creating a specifically-named file: RewriteCond %{HTTPS} off RewriteCond system/force-https -f RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` This is untested, not sure if the relative path like this will always work. Also, not sure if this file should live inside system, or maybe in the root for extra visibility (or maybe be called FORCE-HTTPS, or .FORCE-HTTPS to hide it, or...).
matthijskooijman commented 2020-08-06 10:43:38 +00:00 (Migrated from github.com)

One related thought is that in addition to forcing HTTPS, you might also want to force a specific domain when multiple aliases are available (e.g. always redirect example.com to www.example.com, or example.org to example.com). This is very similar to forcing HTTPS (including the same caveats about locking yourself out), so it would be good to implement this in the same way (possible using a single file, e.g. system/force-url that would contain https://www.example.com (but could maybe also contain //www.example.com to only force the domain or https:// to only force the protocol?).

Forcing a specific host (without hardcoding it in the .htaccess) probably requires handling this from PHP, but that can still be configured using a file (rather than an entry in the hypha.xml) to allow easy recovery in case of lockout.

One related thought is that in addition to forcing HTTPS, you might also want to force a specific domain when multiple aliases are available (e.g. always redirect example.com to www.example.com, or example.org to example.com). This is very similar to forcing HTTPS (including the same caveats about locking yourself out), so it would be good to implement this in the same way (possible using a single file, e.g. `system/force-url` that would contain `https://www.example.com` (but could maybe also contain `//www.example.com` to only force the domain or `https://` to only force the protocol?). Forcing a specific host (without hardcoding it in the .htaccess) probably requires handling this from PHP, but that can still be configured using a file (rather than an entry in the hypha.xml) to allow easy recovery in case of lockout.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
harmen/hypha#247
No description provided.