10

I hope anybody can give me some ideas to my problem. I am trying to apply SameSite cookie to make session work but it seems it doesn't work. The visited site html:

<iframe src="https://www.example.com/test/iframe.php"></iframe>

Iframe source site:

    <?php
    header('Set-Cookie: cross-site-cookie=PHPSESSID; SameSite=None; Secure');
    session_start();
    if(!isset($_SESSION['test'])){
        echo 1;
        $_SESSION['test'] = 'ee2';
    }else{
        echo $_SESSION['test'];
    }

If I visit the website, I still receive A cookie associated with a cross-site resource at https://www.example.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. message in browser console and session is not saved.

Strange thing is that the cookie has been actually set: enter image description here

Am I missing something? Why do I get this message in console if cross-site-cookie is set and what could be reasons for session to not work? I am using php 7.1.33. If I open iframe directly, it works and it also works properly if I open the site with browser where I haven't enabled the SameSite by default cookies flag for testing.

JohnyFree
  • 1,319
  • 3
  • 22
  • 35
  • `$_SESSION['test']` what is the value? ur setting a cookie not the session. –  Feb 10 '20 at 19:49
  • Yes but session seems to not work because of PHPSESSID cookie I guess. The value will be always empty, even if I refresh the page, value doesn't get stored into $_SESSION['test']. But if I open iframe directly it will store value 'ee2'. – JohnyFree Feb 10 '20 at 19:54
  • first, call, set the `session` and `cookie` before you can check i the `session` is set or not –  Feb 10 '20 at 20:06

6 Answers6

14

I resolved it by editing .htaccess

<ifmodule mod_headers.c>
Header always edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</ifmodule>
Behiry
  • 575
  • 5
  • 20
  • Note that this breaks Apple Safari 12.x and older have a bug which incorrectly interprets `SameSite=None` as `SameSite=Strict`. Those browsers require that `Set-Cookie` line doesn't say anything about `SameSite` to get the behavior of `SameSite=None`. – Mikko Rantalainen Aug 27 '21 at 13:06
13

Set session & cookies param php: https://www.php.net/manual/en/function.session-set-cookie-params.php Browser: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

<?php
session_set_cookie_params(["SameSite" => "Strict"]); //none, lax, strict
session_set_cookie_params(["Secure" => "true"]); //false, true
session_set_cookie_params(["HttpOnly" => "true"]); //false, true
session_start(); //everything before this

OR php.ini:

[Session]
session.cookie_samesite = "Strict"
session.cookie_secure = 1
session.cookie_httponly = 1
LisaLisa
  • 411
  • 1
  • 7
  • 18
RoCkHeLuCk
  • 199
  • 1
  • 5
  • 2
    This is the answer, but keep in mind that setting `Secure` or `HttpOnly` to *anything*, including `false`, will enable it in the cookie. To turn off either of those properties, don't set them to anything, that is, don't call `session_set_cookie_params` on them. – Mahn Sep 11 '20 at 15:45
5

I temporary resolved my problem using htaccess:

Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
JohnyFree
  • 1,319
  • 3
  • 22
  • 35
4

I resolved it by:

<?php

session_start();
header('Set-Cookie: PHPSESSID= ' . session_id() . '; SameSite=None; Secure');
João do Site
  • 41
  • 1
  • Please restore your question, so that this thread can still be useful for future readers. They might encounter the same issue as you did. – Neskews Nov 18 '20 at 18:12
1

I wrote a class for this.

https://github.com/ovunctukenmez/SameSiteSessionStarter

It also checks if the browser supports samesite parameter properly.

Instead of session_start();
Use like the this:

<?php
require_once 'SameSiteSessionStarter.php';

//start samesite none php session
SameSiteSessionStarter::session_start();
jetblack
  • 600
  • 4
  • 10
1

I found that this worked for me - setting SameSite as "None" - and some more info on what that means here.

Apparently, browsers no longer allow you to set whatever you want in an iframe, I was trying to handle a session in an iframe, loaded on a different domain and while doing that, I noticed that a different session was being created for the OTHER domain instead of what I was loading in the iframe. This seems to have fixed it. I am still testing but it's the first thing that worked since I started looking for a fix this morning.

sitesalt
  • 55
  • 7