Opened 11 years ago
Closed 7 years ago
#27954 closed task (blessed) (duplicate)
Add FORCE_SSL option to enable HTTPS everywhere on the site
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.0 |
Component: | Security | Keywords: | https has-patch needs-testing has-unit-tests |
Focuses: | Cc: |
Description
We have the option to FORCE_SSL_ADMIN and FORCE_SSL_LOGINs, but not to FORCE_SSL for everyone everywhere.
Aside: It appears wordpress.com force's SSL everywhere
Attachments (3)
Change History (35)
#3
@
11 years ago
I've looked at this before. I see two ways forward:
- There is a force_ssl_content() function in multisite that isn't actually used and could be repurposed for this.
- We could simply detect if the home URL and site URL use the https protocol, and if so, force it for everything (including login and admin). It could be handled for the frontend inside canonical pretty easily, though to properly support this long-term we'll want to start to leverage HSTS.
#5
in reply to:
↑ 4
;
follow-up:
↓ 6
@
11 years ago
Replying to mordauk:
Seems detecting if home or site URL use HTTPS would work fine.
Yep. Seems a bit overkill to add a define when changing the two URLs force SSL site-wide already.
#6
in reply to:
↑ 5
@
11 years ago
Replying to Denis-de-Bernardy:
Yep. Seems a bit overkill to add a define when changing the two URLs force SSL site-wide already.
I tried changing both WordPress Address (URL) and Site Address (URL) to https first actually. That does make more sense to me then adding "FORCE_SSL"...
#7
@
11 years ago
- Component changed from General to Security
- Milestone changed from Awaiting Review to 4.0
- Type changed from feature request to task (blessed)
#8
@
11 years ago
- Owner set to nacin
- Resolution set to fixed
- Status changed from new to closed
In 28610:
#9
@
11 years ago
- Keywords needs-unit-tests added
- Resolution fixed deleted
- Status changed from closed to reopened
I've got some unit tests to go onto this.
#16
follow-up:
↓ 20
@
11 years ago
Awesome work! Is there a check to prevent forcing HTTPS on the frontend of network subsite using a mapped domain since a wildcard cert only covers the primary site frontend (domain.com) and *.domain admin areas?)
#18
@
10 years ago
- Keywords needs-patch added
- Milestone changed from 4.0 to Future Release
wonderboymusic reverted the test in [30160]. This ticket should be reopened, as it has some cascading consequences. See eg https://core.trac.wordpress.org/ticket/15928#comment:81.
#20
in reply to:
↑ 16
@
10 years ago
Replying to Just a guy:
Awesome work! Is there a check to prevent forcing HTTPS on the frontend of network subsite using a mapped domain since a wildcard cert only covers the primary site frontend (domain.com) and *.domain admin areas?)
Just a note: I run a multisite site network with a validated Wildcard securing login/admin at original network addresses, however I am using CloudFlare to provide SSL for my mapped domains (alternatively, one could be using SNI & single certs)...so, this exists and should be allowed :)
This ticket was mentioned in Slack in #core by sergey. View the logs.
9 years ago
#23
@
9 years ago
- Milestone changed from 4.4 to Future Release
Going to look at this as part of more comprehensive HTTPS work.
#25
@
9 years ago
- Keywords has-patch needs-testing added; needs-patch removed
27954.diff uses canonical redirects to redirect requests on the frontend to HTTPS if the FORCE_SSL constant is set to true.
#27
@
9 years ago
- Keywords has-unit-tests added; needs-unit-tests removed
27954.3.diff adds unit tests which ensure that redirect_canonical()
always redirects to HTTPS if FORCE_SSL
is set to true.
This ticket was mentioned in Slack in #core-http by johnbillion. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by benoitchantre. View the logs.
7 years ago
#31
in reply to:
↑ 30
@
7 years ago
Replying to westonruter:
There's this ticket and there is #28521. Should this be closed and the current status moved over to #28521?
Yes, probably.
This ticket focuses on the HTTP redirect to the HTTPS URL, whereas #28521 is about rewriting local URLs in the HTML sourcecode to HTTPS. But these two things really go together and I'm not sure if it makes sense to have two separate tickets for them.
I like the sound of this. Count me in.