Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Security improvements, Update manager |
Issue Summary
Splitting this off into a separate issue as a followup from both:
#1577: Mapping privilege separation on non-SSL/SSL
#607008: Fix bugs in https support and force using https for authorize.php if available
We're now exceptionally close to having Drupal more secure by using https for important things when available. Sadly, all the plumbing is in place (or getting fixed), but we stopped short of the checkbox to actually protect the login forms. :( I can't believe we're going to go another major release relying on contrib to solve what is so obviously a core problem.
A) At the very least we need a checkbox somewhere that sets $form['#https'] = TRUE for all login forms (user_login, user_login_block, etc).
B) We should consider a setting for making all POST actions secure.
C) We should have a setting for making all of admin/* secure.
D) We should have a text area for other URLs to make secure, which supports wildcards (like the block visibility text areas).
E) We should have a little AJAX magic in install.php to test if https works, and if so, to default (A) to TRUE, and set this slightly weird global variable 'https' to TRUE so that everything else works.
Given that Update manager is prompting you for your SSH password over http unless we give people a way to turn this on, I'm calling this a release-blocking critical task...
Comments
#1
Adding a few more relevant tags...
#2
#3
subscribing
#4
I'd love to see all of this. But given the timeframe, how about doing only A)?
#5
I'd love to see all of this. But given the timeframe, how about doing only A)? ;-)
#6
No one worked on this prior to alpha 1. Better luck next release, I guess. :(
#7
Hello,
I was wondering if Secure Pages module (http://drupal.org/project/securepages) will be needed in Drupal 7 with this feature in core? Or will it need to be ported as the UI is being developed in D8?
Thanks!
#8
I'm pretty sure either "8.x" or "Release blocker" are wrong for this issue?!
#9
*sigh*
#10
Next year in Jerusalem, I guess. Tracking.
#11
#12
Downgrading all D8 criticals to major per http://drupal.org/node/45111
#13
Following.
#14
I looked around in admin for a sensible place. If there would be more security-related options than a single checkbox it could have its own 'Security' section in the 'System' category. Without adding a new category, "admin/config/system/site-information" looks like the least crappy option. Thoughts?
#15
Sounds like a feature request to me. Major "tasks" are now preventing adding new features to Drupal core per the new policy at http://drupal.org/node/1201874. There are a lot of other worthy features out there that can't move forward while we're over our threshold.
#16
I'm also not sure this is even "major" priority. I'd suggest further improvements to the API before moving on to the UI.
Cases in point: Secure pages module doesn't have a stable Drupal 7 release yet due to core bugs, and Secure login module had to re-implement the core API with $conf['https'] at its default value (FALSE) so as to avoid this setting's mandatory creation of insecure authenticated sessions when users login securely.
$conf['https'] could be renamed to $conf['https_session_insecure'] or something, as it's really not needed or wanted by all HTTPS sites, even those that do have both HTTP and HTTPS sites (the use case for $conf['https'] = FALSE is sites that support anonymous sessions on the HTTP site but require all authenticated sessions to use the HTTPS site).