Port Secure Pages to Drupal 8

I've created a document which contains architecture of D8 module and mapping of removed D7 functions to classes/methods in D8.

https://docs.google.com/document/d/1e-eRRLOYGnvmdABooQbQw1EZRlpxtbaWFb9E...

As per #2611402: [securepages] Secure Pages, @suthagar started a port in his own sandbox. Looks like we need some coordination here :)

I took that initial commit over and continuing with the porting at https://www.drupal.org/sandbox/goba/2632462

Progressing well at https://www.drupal.org/sandbox/goba/2632462, HTTPS detection and path/role based redirection works.

Secure pages is probably going to run into mixed content warnings and CORS errors (for things that care about CORS, like fonts) that I hit with secure login module, due to absolute HTTP URLs in render caches and aggregated CSS used by HTTPS pages (for CORS errors, the opposite is a problem too).

@mfb: I don't think that is a new problem at all (with Drupal 8)?

@Gábor these are new issues because Drupal 8 has additional cached markup (which may contain absolute URLs but is used across different base URLs), and uses absolute URLs rather than root-relative URLs in aggregated CSS. See:

• #1377840: Caching does not properly respect protocol (a problem when dealing with https);
• #1494670: References to CSS, JS, and similar files should be root-relative URLs: avoids mixed content warnings & fewer bytes to send;
• #2375103: Regression: aggregated CSS should use server-relative URLs inside url() calls within the CSS file; and
• #2611420: Aggregated CSS assumes HTTP, causes mixed content warning when accessed via HTTPS.

Thanks for those links! Anything to do about it in securepages?

Well that's a good question. It might be better to focus on fixing the issues in core rather than trying to work around them in secure pages module?

Agreed that those things should be fixed in core. I'm working on patches for all issues listed in #9.

Whew. I managed to mark 3 of the 4 issues in #9 as duplicates of the 4th issue #1494670: References to CSS, JS, and similar files should be root-relative URLs: avoids mixed content warnings & fewer bytes to send — see #1494670-73: References to CSS, JS, and similar files should be root-relative URLs: avoids mixed content warnings & fewer bytes to send. I've also rerolled the patch there and incorporated the work I did in the other issues. Please review!

This is patch to the module i have put in the match path function, role and also add some code to the .install file , Also this is a task for google code in

@Phillip Junior: your patch includes ALL the files. Can you upload just your changes?

Here is the match path function withe the role function under it and I add the updated uninstall feauture to the .install file

@Gabor Hojtsy, wanted to check on the status here as there hasn't been any activity in the last few months. I compared the functionality here to D7 and it looks like most things have been ported, and updated for D8. There are two issues on the sandbox without any activity for a while. I would like to assist in getting this to a stable D8 release, would like to have a quick discussion on what would be needed for at least an alpha-release and be added to the main repo here.

I created a new discussion over at https://www.drupal.org/node/2818063, to make this sandbox the official 8.x-1.x version on the project repo. We can either close that as a duplicate and continue the conversation, or vice versa.

There are a few bugs with the sandbox, but I think they can be fixed hopefully without too much effort. But I think we need to have an "official" version on the main project where we can focus development work. I will be working to get a stable release that is feature compatible with the D7 version as soon as possible.

+1 for someone joining as a new comaintainer to copy over the sandbox into a new 8.x-1.x branch so this can start gaining some momentum.

I am back! I have not done much since my accident but I am not back working on my modules.

I have started by pulling in all the commits from the 2 sandboxes, and now I am going to be pulling getting it working.

I have also learned of the new conditions API here at DrupalCon Vienna and I am eager to use this in Secure pages. So all the requests to make this work by node type, user role, etc, etc I hope to have working so the admin can just enable them as a service or something and they will just work.

Related module for Drupal 8: https://www.drupal.org/project/securelogin

Should we just recommend moving to https://www.drupal.org/project/securelogin in the interim (because it has a stable release)? Not sure what is lost in the process.

I think it would be fine to recommend Secure Login module. The main difference is that Secure Pages supported mixed-mode (HTTP and HTTPS) sessions, whereas Secure Login module makes no effort to do so; it is instead focused on redirecting forms to HTTPS (most notably login forms such that authenticated sessions are secure, but actually any forms).

Sites that have HTTPS should be focused on getting all of their traffic on HTTPS anyway, doing mixed-mode no longer makes sense. ($0.02)

I don't know if mixed-mode ever made sense, but now that so many sites have moved to HTTPS thanks to Let's Encrypt, GDPR, etc. it's hopefully not worth arguing about anymore.. :)

Thanks for all the help, I have marged everything back into the main branch and created the release for the 8.x development branch.

I am closing this as we can move forward with new issues and get to a stable release.

Making this issue easier to find 🤓

By the way, I made an issue for linking from the Secure Pages module page to Secure Login as an alternative module: #3253190: Add a link to Secure Login module on Secure Pages module page (as it might be difficult for users to find these old closed issues :)