@eklipse2009
The THIRD parameter is indeed set to ZERO and that means that this cookie will remain in the client's browser for only as long as the browser remains open. 'Ephemeral' (or session) as I mentioned in my last post.
Which means that if the user keeps the browser open for, say, months together the cookie will always be returned by the browser to the server.
However, that cookie will *not* be accepted by Couch after 12 hours of the time it was first issued. This is ensured by the cookie content (implemented using the industry standard ' Secure Cookie Protocol - by Alex X. liu') that has the initial issue time within it.
When a cookie is presented, the login function (function _authenticate_cookie() in auth.php) compares the contained time with the current time and rejects the cookie if found stale
It is enough for what it is meant to be - that is to securely tell the server the original issue time of the cookie. Not sure why it wouldn't work on *any* version of PHP.
Allow me to explain.Sorry, cheesypoof, but you're terribly wrong, unless my eyes deceive me.
I've read the logic from the CODE.
The line of the code you are referring to is this -setcookie's function THIRD parameter was set to ZERO instead of $cookie_expiry, which in turn was set to 12 hours. Instead of being passed as a parameter to a function, it is only used in HASH, which is clearly not enough.
- Code: Select all
setcookie($this->cookie_name, $cookie, 0, $this->cookie_path, null, null, true);
The THIRD parameter is indeed set to ZERO and that means that this cookie will remain in the client's browser for only as long as the browser remains open. 'Ephemeral' (or session) as I mentioned in my last post.
Which means that if the user keeps the browser open for, say, months together the cookie will always be returned by the browser to the server.
However, that cookie will *not* be accepted by Couch after 12 hours of the time it was first issued. This is ensured by the cookie content (implemented using the industry standard ' Secure Cookie Protocol - by Alex X. liu') that has the initial issue time within it.
When a cookie is presented, the login function (function _authenticate_cookie() in auth.php) compares the contained time with the current time and rejects the cookie if found stale
- Code: Select all
$cookie = $FUNCS->cleanXSS( $_COOKIE[$this->cookie_name] );
list( $username, $expiry, $hash ) = explode( ':', $cookie );
if( time() < $expiry ){
if( $cookie == $this->create_cookie($username, $expiry) ){// if cookies match
...
it is only used in HASH, which is clearly not enough.
The thing MIGHT work with very old PHP version though.
It is enough for what it is meant to be - that is to securely tell the server the original issue time of the cookie. Not sure why it wouldn't work on *any* version of PHP.
I think, I already explained that the variable is being used as intended.When a variable is set a value and is not used where intended, it IS a bug, not a feature.
You'll find it in the docs about extended-users (http://www.couchcms.com/docs/extended-entities/post.htm) which is what it was meant for, for now.version 1.4.5
There is not documented way to use $rememberme variable.
I think your initial confusion about the cookies life-time (i.e. being sent by the browser back to the server) and the validity-time (being accepted by server if not more that 24 hours old) must have been resolved by the discussion above so that should answer this point.But the logic suggests that even with NO rememberme button checked, the cookie must last for 24 hours.
Then the logic suggests that IF rememberme is not checked, the cookie expiration parameter is yet again set to ZERO instead of 24 hours.