Drupal lacks any organized method (that I am aware of) of controlling which pages can/must be accessed via SSL. Some modules (e.g. authorize_net in the upcoming E-Commerce release) hard-code certain behaviors, and a few various hacks have been proposed in the forums, but generally these approaches conflict with each other and lead to complexity and not using SSL when it should be (e.g. all user logins and registrations, admin pages with security-critical data (e.g. authorize_net merchant account passwords) or for that matter all admin pages, etc.).
I propose a simple module to handle this centrally, which I'll call sslcontrol for now. It has a settings page which lets the admin declare which pages should be SSL-protected just like declaring where blocks should appear. It also defines hook_sslcontrol(...) which lets modules declare that the current URL should be SSL-protected.
In sslcontrol_menu(), the module combines its own settings and the results of hook_sslcontrol() to decide if the current page should be protected. If so, and if the page is not already using SSL, it redirects to the SSL-equivalent page. If not, and if the page is using SSL, it redirects to the non-SSL-equivalent page. It would be an admin configuration error to define a POST-targeted page as requiring SSL when its submitting page is not, or vice versa, since you cannot redirect in that situation without generating a browser warning dialog.
DDEV is the official local development tool of Drupal. And like Drupal, DDEV depends on the support of the open source community.
