[CLOSED] CGI cookie add samesite=lax?
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
kqha · 2020-05-20 05:34

My CGI app throw a warning in Firefox says something about in the
future the cookie will be rejected because it use samesite=none
parameter in unsecure (non-https) connection. After googling a bit, it
appears I need to change the default samesite parameter to lax
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-
Cookie/SameSite) to suppress the warning and prevent the problem arise
in the future.

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i Procedure
TMyCGIHandler.HandleRequest(ARequest : Trequest; AResponse :
TResponse);begin  ....  ....  with AResponse.Cookies.Add do  begin   
 name:='mycookiename';     value:='mycookievalue';  end;end; 
Any idea how to add samesite parameter? I see expires, secure, etc in
TCookie but no samesite.

----------------------------------------------------------------------
lucamar · 2020-05-20 06:55

You should specify which "framework" you're using and which version of
fpc/lazarus you're using.

Assuming you're using fcl-web (+ weblaz package), the underlying
implementation of how a cookie is sent is in
$(FPCSource)/packages/fcl-web/src/base/httpdefs.pp, in the method
TCookie.GetAsString.

According to that, it seems it never ever sends a "samesite" attribute
which, as specified in the document you cited, should mean that modern
browsers take it as meaning "samesite=lax".

In any case, the implementation of TCookie is so simple  that it
shouldn't be too dificult to add a new "samesite" property either in
the base class (and sending a patch through the issue tracker) or in a
derived one.

A very basic example might be something like:

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i unit
CookieEx; {$mode objfpc}{$H+} interface uses  Classes,
HTTPDefs; type   TSameSite = (ssLax, ssStrict, ssNone, ssNull);   {
TCookie }   TCookie = class(HTTPDefs.TCookie)  private    FSameSite:
TSameSite;    function GetAsStringEx: String;  public    constructor
Create(ACollection: TCollection); override;    property SameSite:
TSameSite read FSameSite write FSameSite;    property AsString: String
read GetAsStringEx;  end; implementation { TCookie } function
TCookie.GetAsStringEx: String;const  ssStrings: array [ssLax..ssNone]
of String = ('Lax', 'Strict', 'None');  sSameSite = 'SameSite:
%s';begin  Result := GetAsString;  if sSameSite <> ssNull then  Result
:= Result + '; '          + Format(sSameSite,
[ssStrings[FSameSite]]);end; constructor TCookie.Create(ACollection:
TCollection);begin  inherited Create(ACollection);  FSameSite :=
ssNull;end; end.
Note that this is just an example! The preferred (and correct!) way
is, of course, to patch the base class in HTTPDefs; since it's
inmediately used inside that same unit for TCookies, TResponse, etc.
using a derived class in your own program would mean that your
"cookie" class wouldn't match the one used in HTTPDefs and that would
lead to some rather serious bugs.

HTH

----------------------------------------------------------------------
trev · 2020-05-20 07:11

The Draft IETF HTTPbis - FC6265bis document for the gory
implementation details. Note: it is a draft dated April 2020 from our
favourite duo: Google and Apple. It has not been approved (yet
anyway).

----------------------------------------------------------------------
lucamar · 2020-05-20 07:25

Yeah, that the attribute is so new (relatively speaking) is probably
why it's not included in TCookie, whereas those defined in RFC-6265
are all there.

Problem is that while it's supported by all major browsers, the
default behaviour isn't quite yet "set in stone"; hence the
need/convenience of adding a "proposed pacth" to the tracker to be
able to set it explicitely.

----------------------------------------------------------------------
kqha · 2020-05-21 14:47

Quote from: lucamar on May 20, 2020, 08:55:29 amYou should specify
which "framework" you're using and which version of fpc/lazarus you're
using.

Assuming you're using fcl-web (+ weblaz package), the underlying
implementation of how a cookie is sent is in
$(FPCSource)/packages/fcl-web/src/base/httpdefs.pp, in the method
TCookie.GetAsString.

According to that, it seems it never ever sends a "samesite" attribute
which, as specified in the document you cited, should mean that modern
browsers take it as meaning "samesite=lax".

In any case, the implementation of TCookie is so simple  that it
shouldn't be too dificult to add a new "samesite" property either in
the base class (and sending a patch through the issue tracker) or in a
derived one.

A very basic example might be something like:

Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i unit
CookieEx; {$mode objfpc}{$H+} interface uses  Classes,
HTTPDefs; type   TSameSite = (ssLax, ssStrict, ssNone, ssNull);   {
TCookie }   TCookie = class(HTTPDefs.TCookie)  private    FSameSite:
TSameSite;    function GetAsStringEx: String;  public    constructor
Create(ACollection: TCollection); override;    property SameSite:
TSameSite read FSameSite write FSameSite;    property AsString: String
read GetAsStringEx;  end; implementation { TCookie } function
TCookie.GetAsStringEx: String;const  ssStrings: array [ssLax..ssNone]
of String = ('Lax', 'Strict', 'None');  sSameSite = 'SameSite:
%s';begin  Result := GetAsString;  if sSameSite <> ssNull then  Result
:= Result + '; '          + Format(sSameSite,
[ssStrings[FSameSite]]);end; constructor TCookie.Create(ACollection:
TCollection);begin  inherited Create(ACollection);  FSameSite :=
ssNull;end; end.
Note that this is just an example! The preferred (and correct!) way
is, of course, to patch the base class in HTTPDefs; since it's
inmediately used inside that same unit for TCookies, TResponse, etc.
using a derived class in your own program would mean that your
"cookie" class wouldn't match the one used in HTTPDefs and that would
lead to some rather serious bugs.

HTH

Thanks for your info, I'll take note of your code if somehow the
problem become real serious and need quick patch, which shouldn't be
in near future due to implementation of said parameter are relatively
new and undecided yet (I myself just notice the warning a few days ago
after updating Firefox).