[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