php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #70000 First-Party-Only Cookies
Submitted: 2015-07-06 09:52 UTC Modified: 2015-07-06 11:16 UTC
From: craig at craigfrancis dot co dot uk Assigned:
Status: Suspended Package: HTTP related
PHP Version: Irrelevant OS: N/A
Private report: No CVE-ID: None
View Developer Edit
 [2015-07-06 09:52 UTC] craig at craigfrancis dot co dot uk 
Description:
------------
Google Chrome is currently considering implementing First-Party-Only Cookies.

https://code.google.com/p/chromium/issues/detail?id=459154

https://tools.ietf.org/html/draft-west-first-party-cookies-01

https://www.chromestatus.com/feature/4672634709082112

This is an interesting security feature, so should the setcookie() function be updated to also support this?

http://php.net/setcookie

bool setcookie ( string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false  [, bool $firstonly = false ]]]]]]] )

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-06 10:42 UTC] requinix@php.net
-Status: Open +Status: Suspended -Type: Bug +Type: Feature/Change Request
 [2015-07-06 10:42 UTC] requinix@php.net 
Most recent draft: https://tools.ietf.org/html/draft-west-first-party-cookies-03

The RFC is still in draft, Chromium has had some back-and-forth regarding an actual implementation (or so I read in the revision history), and apparently there's been some question regarding Chromium's behavior versus Firefox's
  https://groups.google.com/a/chromium.org/d/topic/blink-dev/ZvMEJMSU6po/discussion

Supporting First-Party-Only seems like a no-brainer to me, but I'm thinking we'd best wait until the proposal reaches RFC status. Maybe even until it reaches the major browsers.

(setcookie's signature is getting unwieldy - maybe there can be some additional work with it?)
 [2015-07-06 10:58 UTC] craig at craigfrancis dot co dot uk
-Summary: First-Party-Only Cookies +Summary: craig@craigfrancis.co.uk
 [2015-07-06 10:58 UTC] craig at craigfrancis dot co dot uk 
Agreed, it was more to start the discussion now (although perhaps not waiting for too many implementations, as I know it takes a while for the likes of RedHat to get new versions of PHP into a shipping product).

And I agree that the setcookie signature is getting a bit too long:

setcookie('name', 'value', 0, '/', 'example.com', true, true, true);

Out of interest, to support this (and potentially other) flags now, I suspect it will involve re-creating the setcookie() function with a header() call?
 [2015-07-06 10:59 UTC] craig at craigfrancis dot co dot uk
-Summary: craig@craigfrancis.co.uk +Summary: First-Party-Only Cookies
 [2015-07-06 10:59 UTC] craig at craigfrancis dot co dot uk 
/ Password manager changing subject.
 [2015-07-06 11:16 UTC] requinix@php.net 
>Out of interest, to support this (and potentially other) flags now, I suspect it
>will involve re-creating the setcookie() function with a header() call?
Hard to say - there's not much precedent to look to. There are a couple PHP RFCs worth mentioning:
  https://wiki.php.net/rfc/named_params (stalled)
  https://wiki.php.net/rfc/skipparams (declined)

The most "obvious" solution would be an options array, like
  bool setcookie(string $name [, string $value [, array $options ]])
or, for just the flags,
  $name [, $value [, $expire [, $path [, $domain [, array $options ]]]]]
strtr() is an example of that kind of duality of usage.

But again, hard to say. Changing a function as important as this one would likely require some discussion internally.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Nov 02 23:00:02 2025 UTC