TWebResponse.SetCookieField fehlt Support für "SameSite"

[Rolf Frei]

Ab 2020 oder Version 80 für Chome sollten Cookies mit dem SameSite attribute ergänzt werden, damit sie noch funktionieren, respektive vom Browser übermittelt werden. Ich möchte da nun eigentlich SameSite=Strict für alle meine Cookies verwenden. Wie ich festgestellt habe fehlt aber Delphi der Support dieses Cookie Attribute! (siehe Web.HTTPApp.pas TCookie)

Hier eine Beschreibung was SameSite genau ist:
https://web.dev/samesite-cookies-explained/

Nun habe ich versucht das mit SetCustomHeader zu lösen. Da alle Cookies den selben Headernamen "Set-Cookie" erhalten, geht das nicht. Als Resultat bekomme ich so immer nur ein einziges Cookie, da dort der Wert über den Namen "Set-Cookie" immer ersetzt wird. Mit SetCustomeHeader ist das also auch nicht lösbar. Direktes Abfüllen von CustomHeaders geht auch nicht, weil da wieder mit Name/Values gearbeitet wird und ich so auch immer nur den Wert des ersten Cookie Eintrags für jedes "Set-Cookie" bekomme.

Wie soll ich das nun lösen? Sehe da absolut keine Möglichkeit. Ändern der TCookie Klasse kommt auch nicht in Frage, da so fast alle Web Units, durch die Änderung am Interface, inkompatibel werden.

Bin echt geschockt, dass das in der aktuellen Delphi Verison noch fehlt. Das Cookie Attribute SameSite ist ja schon etwas älter. Dass das in einer alten D7 Version noch nicht enthalten ist, vestehe ich ja noch, aber dass das selbst in der aktuellen Version noch fehlt?!

[Bbommel]

Hi Rolf,

ich bin gerade auch darüber gestolpert, weil mein Firefox mich im Debug-Fenster warnt, dass er meine Kekse zukünftig nicht mehr akzeptiert, wenn ich nicht ein SameSite-Attribut setze.

Da ich gesehen habe, dass das selbst in der 10.4 noch immer nicht enthalten ist, wäre die Frage, ob du zwischenzeitlich einen funktionierenden Workaround gefunden hast?

[TurboMagic]

Wenn eine Subscription bei EMBT voirhanden ist evtl. mal einen offiziellen Supportfall dort aufmachen.
Evtl. wissen die noch was...

[Bbommel]

Stimmt, ein Ticket aufzumachen, wäre noch eine Möglichkeit. Ich habe bei mir jetzt erstmal die größte Dramatik rausbekommen, indem ich das Cookie als "Secure" kennzeichne (es wird im produktiven Einsatz ja eh über https gearbeitet), dann warnt der Browser nicht mehr.

Ein anderer Workaround, den ich jetzt schon getestet habe, aber weil das obige ja funktioniert, jetzt noch nicht scharf geschaltet habe, wäre es, die neue ID auf anderem Weg an den Client zu senden und dann vom Client aus per Javascript zu setzen. So lässt sich dann auch problemlos das SameSite-Attribut setzen.

[Rolf Frei]

Du kannst das so mache wie ich im Report gemeldet habe, nur ist das keine schöne Lösung, weil man da an den Originalsourcen herumbasteln muss. Leider ist der TCookie Code so unsauber programmiert, dass da garnichts virtual ist. Wäre da GetHeaderValue virtual, wäre es relativ einfach zu lösen gewesen, aber so wie es aktuell ist, kommt man nicht drummherum in den Quellsourcen von Delphi Anpassungen zu machen und eine eigegne TCookie Klasse zu verrweden. Direkt im TCookie kann man auch nichts anpasen, da das sonst zu inkompatiblen (Interface) Units führt.

Delphi-Quellcode:

unit RFWebAppCookie;

interface

uses
  HTTPApp;
  
type
  TRFCookie = class(HTTPApp.TCookie)
  private
    FSameSite: String;
  protected
    function GetNewHeaderValue: string;
  public
    property SameSite: String read FSameSite write FSameSite;
    property HeaderValue: string read GetNewHeaderValue;
  end;


implementation

uses
  SysUtils;

{ TRFCookie }

function TRFCookie.GetNewHeaderValue: string;
begin
  Result := Format('%s=%s; ', [HTTPEncode(Name), HTTPEncode(Value)]);
  if Domain <> '' then
    Result := Result + Format('domain=%s; ', [Domain]);  { do not localize }
  if Path <> '' then
    Result := Result + Format('path=%s; ', [Path]);      { do not localize }
  if Expires > -1 then
    Result := Result +
      Format(FormatDateTime('"expires="' + sDateFormat + ' "GMT; "', Expires),  { do not localize }
        [DayOfWeekStr(Expires), MonthStr(Expires)]);
  if SameSite <> '' then
    Result := Result + 'SameSite=' + SameSite + '; ';
  if Secure then Result := Result + 'secure';  { do not localize }
  if Copy(Result, Length(Result) - 1, MaxInt) = '; ' then
    SetLength(Result, Length(Result) - 2);
end;

end.

An den Stellen in der Orignalsource wo TCookie verwendet wird muss nun diese neue Klasse benutzen. Weiss akteull nciht mehr genau wo und was ich da genau geändert habe. Müsste das zuerst neu zusammen suchen.

[Bbommel]

Falls es noch wen interessiert oder jemand per Google hier bei dem Thema landet: Emba hat in 10.4.2 versucht, "SameSite" für Cookies umzusetzen. Zumindest aber, wenn man das für Web-Server-Anwendungen (WebBroker) nutzt, bringt das nichts, weil dort zum Senden der Antwort Indy benutzt wird und Indy verschluckt dieses neue Attribut wieder, weil es dort noch immer nicht bekannt ist.

Ich hab mal einen neuen QP-Eintrag dazu erstellt.

[Rolf Frei]

Ich nutze Webbroker (ISAPI/CGI) mit IIS und da scheint der Fix zu funktionieren, zu mindest wenn ich die Sourcen studiere was da gefixt wurde. Habe das aber aktuell so selber noch nicht im Einsatz und weiss nicht ob ich da eventuell was übersehen habe. Wenn das aber nur Indy Server betrifft ist es ein Indy Problem und nicht ein Webbroker Problem. Das betrifft also dann nur Standalone Webserver Anwendungen die auf Indy aufbauen.

Hab mal deinen Report gelesen und finde ihn etwas irreführend/unklar, weil da von Webbroker geredet wird, obwohl es vermutlich nur den Indywebserver betrifft. Bei Verwendung eines Webbrowsers mit IIS und ISAPI/CGI sollte es eigentlich funktionieren oder ich habe dein Problem nicht genau verstanden, weil du da schreibst, dass der WebBroker an den Server sendet. Das kann ich nicht nachvollziehen, weil WebBroker ein Server Teil ist und das an den Clients sendet und nicht umgekehrt. WebBroker sendet nichts an einen Server sondern an einen Client (Browser).

Das Cookie wird ja nur vom Server gesendet und beim Erstellen des Cookies benötigt, damit das Attribute beim Browser ankommt. Danach ist das eine Sache des Browsers (Clients) wie das bei folgendene Anfragen an den Webserver an den Server gesendet wird. Ich glaube, dass das SameSite Attribute vom Browser garnicht gesendet werden muss, weil das ein Clientsache ist, wie man da die Cookies bahandelt und bestommen wird, ob es gesendet wird oder nicht. Der Server muss davon eigentlich nichts mehr wissen.

Was mir aber an der Umsetzung des Bugs betrifft, bin ich leider kein Fan von dem Fix. Da wurde eine Helperklasse gemacht. Sowas finde ich nur als Workaround akzeptabel um einen Interface Break zu verhindern (inkompatible DCU's). Das müsste also zumindest in 10.5 in die Basisklasse und nicht bei einem solchen Murks bleiben. Ich finde es überaupt nicht gut wie vieles da mit Helperklassen gefixt wird, anstatt das sauber in der Basisklasse zu implementieren.

[Bbommel]

Stimmt, das Indy-Zeug, das hier für das eigentliche Senden verantwortlich ist, ist bei einer CGI-Lösung nicht relevant. Habe ich im QP noch geändert, dass es um Stand-Alone-Anwendungen geht. Danke für den Hinweis.

Und, ja: Zustimmung zu den Lösungen mit Helferklassen und so, macht so eine Fehleranalyse ja auch nicht einfacher. Ich vermute aber, sie machen das so, damit irgendwelche Kompatibilitäten innerhalb der 10.4-Reihe erhalten bleiben.

[Rolf Frei]

ZurInfo: Habe meine letzte Nachricht noch starkt ergänzt. Vieleicht liest du sie dir nochmals durch. Insbesondere, dass dein Bugreport etwas irreführend ist, weil du da was scheibst, von wegen WebBroker sendet an den Server. Das kann so nicht stimmen und du müsstest da eventuell deinen Report noch etwas klarer machen.

[Bbommel]

Danke für das Feedback und fürs Drübergucken. Es war nur ein Wort, aber das war natürlich Blödsinn und komplett verwirrend - natürlich muss es "sending a response to the client" und nicht "sending a response to the server" heißen.

Und ja, das Problem tritt dann nur im Zusammenspiel mit Indy auf, also bei einem Stand-Alone-Server. Ich habe das mit dem Stand-Alone jetzt an zwei Stellen im Ticket erwähnt, das sollte dann hoffentlich klar genug für die Leute bei Emba sein.