[wp-trac] [WordPress Trac] #42481: Test cookie secure flag prevents non-secure login

[WordPress Trac]

#42481: Test cookie secure flag prevents non-secure login
------------------------------------+------------------------------
 Reporter:  RavanH                  |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  low                     |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:  4.9
 Severity:  normal                  |  Resolution:
 Keywords:                          |     Focuses:
------------------------------------+------------------------------

Comment (by RavanH):

 This bug remains a very nasty one even if it would be on 'edge' cases
 only... And I'm not sure about it being such an edge case actually.

 Take this scenario for example: a WP Multisite with subdomains, open for
 public registration, the main site on domain example.com was created on
 HTTP but has been moved to HTTPS with a Letsencrypt license. Now new sites
 that are created from the front end (public) registration will be on HTTP.

 But since the main site where registration and first login was done over
 HTTPS, the new user will soon run into problems:

 - The first, but very minor, issue is he/she needs to do a second login to
 get into his own fresh new subdomain site admin. Not a big deal, just
 inconvenient and not as it would be if both primary site and subdomain
 site are on the same protocol.

 - Then, after being logged in on the admin, the user will appear to be
 logged out when returning to his site front end (to see changes for
 example) and have no admin bar or edit links. Returning to the admin can
 be done by the browser back button or typing /wp-admin/ so this one too is
 not the most annoying issue.

 - But when he/she tries the theme Customizer, it will fail completely with
 a "Non-existent changeset UUID" error.

 - And no post Preview, of the soon to be published post...

 Specially these last two give a horrible experience for a new user and
 he/she will likely turn elsewhere to blog.

 The only current work-around is either to move the main site back to HTTP
 or to get an expensive wildcard SSL license (at least as long as
 Letsencrypt wildcard challenges remain so elusive to meet) ... Is there
 really no interest in fixing this?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42481#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform