Chrome 80 & SameSite Cookies

Chrome 80 comes out next week ( Feb 17 ) and it will enforce the SameSite Cookie attribute.
LDEV-1236 covers this issue. Does anyone know if cftoken and cfid will have tlhis attribute set?

How will this affect sessions in Lucee?

it’s only going to be an issue if you are doing cross domain stuff, i.e. loading a page from
Lucee from a different domain and expecting the user to be already logged in

I just use an apache rule to set them

Header edit Set-Cookie ^(.*)$ $1;SameSite=Strict

Pete Freitag has instructions for IIS.

Is there any plan to add support for samesite to cfcookie?

I’m adding external auth support to my codebase and realized that Chrome’s samesite cookie rules were preventing my browser from being recognized as logged when I redirect from another domain for a token.

I’d prefer to set the samesite attribute in my code rather than having to modify web server settings with a rule (lots of separate site installations), but Lucee v5.3.6.61 still doesn’t recognize the samesite attribute, even though it looks like ACF does (https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-c/cfcookie.html)

Thanks!

Latest RC, should be stable :slight_smile: already supports them, only you can’t set same site=none due to a bug in the implementation

https://luceeserver.atlassian.net/browse/LDEV-2993

Hey, thanks for the quick response!

I’ll probably wait for the bugs to get worked out though, rather than install RC on client’s servers…

Meanwhile, I wrote quick drop-in replacement function, but I think I uncovered another bug…

void function setCookie(string name, 
                        string value, 
                        expires="", 
                        string path="/", 
                        boolean httpOnly=false, 
                        boolean secure=false, 
                        boolean preserveCase=false, 
                        string sameSite="strict") {

	if (!preserveCase) {
		name = UCase(name);
	}
	var str = "#name#=#value#;Path=#path#;SameSite=#sameSite#";

	if (expires == 'now') {
		str &= ';Max-Age=0';
	} else if (isNumeric(expires)) { // timespan is float value in days
		maxAge = Floor(expires * 86400);
		str &= ';Max-Age=#maxAge#';
	} else if (isDate(expires)) {
		str &= ';Expires=#getHttpTimeString(expires)#';
	} 

	if (httpOnly) {
		str &= ";HTTPOnly";
	}

	if (secure) {
		str &= ";Secure";
	}
	cfheader(name="Set-Cookie", value=str);
}

For expires, I’m passing in a value from CreateTimespan(), which (as far as I understand) is a numeric value representing days. The thing is, isNumeric(expires) returns false and isDate(expires) returns true.

I tried with a numeric literal value and got the expected results (e.g. isNumeric(0.5): true, isDate(0.5): false), but it seems that the number returned from CreateTimespan() is tagged as a Date type when it’s actually a number. In this case, the code above outputs an expired time in 1899 when I pass it a 5 minute timespan.

As a workaround, I’m just checking whether expires > 0 and then if expires > now() rather than using isNumeric and isDate, which seems to work fine.

I’m not sure if this behavior is actually a bug in Lucee or if it’s working as expected. CreateTimespan clearly is a Date/Time function, but the value is also clearly a number that can’t be directly used as a Date type.

Does anybody know what ACF does in this situation?

I think you want getHTTPTimeString() e.g.

<cfset exp=getHTTPTimeString(dateAdd('d',getApplicationMetadata().sessionTimeout,now()))/>

<cfheader name="Set-Cookie" value="cfid=#cookie.cfid#;Path=/;Expires=#exp#;SameSite=None;Secure"/>
<cfheader name="Set-Cookie" value="cftoken=#cookie.cftoken#;Path=/;Expires=#exp#;SameSite=None;Secure"/>