[wp-trac] [WordPress Trac] #42481: TEST_COOKIE and LOGGED_IN_COOKIE secure flag create issues on non-secure login

WordPress Trac noreply at wordpress.org
Fri Jun 15 01:26:16 UTC 2018


#42481: TEST_COOKIE and LOGGED_IN_COOKIE secure flag create issues on 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):

 Update: I created a fairly simple workaround that seems to do the job
 satisfactory.

 The idea is to create separate cookies for SSL and nonSSL requests to
 simulate how AUTH_COOKIE and SECURE_AUTH_COOKIE are treated. I did this by
 adding the following lines to wp-config.php

 {{{#!php
 // Treat the cookie domain: strip off any subdomain (including www) if
 there is one
 // so that logged in status carries across different sub-sites and main
 site after
 // logging in on a sub-site, just as it does after logging in on the main
 site.
 define( 'COOKIE_DOMAIN', implode( ".", array_slice( explode( ".",
 $_SERVER['HTTP_HOST'] ), -2 ) ) );

 // Set up a cookiehash now because we need it next. It may be same as
 default or anything else.
 // Also fixes missing cookiehash bug for sub-network sites in Multi-
 network!
 define( 'COOKIEHASH', md5( 'xxxxxxxxxxxxxxxxxx' ) );

 // SSL aware TEST_COOKIE and LOGGED_IN_COOKIE must be set otherwise cookie
 set on ssl
 // will be ignored on non-ssl login. and WordPress sets no hash on mapped
 domains...
 if ( isset($_SERVER['HTTPS']) && 'on' == $_SERVER['HTTPS'] ) {
         define( 'TEST_COOKIE', 'wordpress_sec_test_cookie' );
         define( 'LOGGED_IN_COOKIE', 'wordpress_sec_logged_in_' .
 COOKIEHASH );
 }
 }}}

 This seems to be enough to completely separate secure from non-secure
 cookies. Once a user is logged in over SSL, cookies with "_sec" in their
 name will be set with the secure flag. The user will need to do a separate
 login when on a nonSSL subsite but once that is done, all will work fine
 because the cookies set at login are with a different (default) name and
 do not have the secure flag.

 Note that the initial COOKIE_DOMAIN define is not strictly needed but has
 a nice advantage: logging in on a subsite will now behave the same as
 logging in on the main site. The user will be logged in across the network
 (as long as on the same protocol!) instead of just the subdomain.

 Only thing I'm wondering: would it be better for security to set a
 different COOKIEHASH for secure versus non-secure cookies? What is that
 hash for anyway? Does it serve like a public/shared key?

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


More information about the wp-trac mailing list