[VOTE] Same Site Cookie RFC

On Mon, Aug 28, 2017 at 12:10 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl

wrote:

Little misunderstanding then. I agree we can better have this PHP 7.3 and
take some time for it. Current votes also suggest that we should go for the
array argument implementation. Since there is only a PR for the extra
argument implementation, it will also take time to have the PR for the
array argument implementation ready. Taken that into account, we should not
want this in 7.2.

Indeed, yes. Assuming the votes continue on this sharp lean towards the
array option, we should just forget all notions of trying to sneak this
into 7.2.

Direct calls in 7.2 and earlier can easily fall back on calling
header('Set-Cookie: ...'); manually, while sessions support is slightly
more complex, but still doable from userspace. I expect if need is deemed
high for this, a drop-in composer package can do 90% of the work
automatically.

-Sara

Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães mail@pmmaga.net:

It'd be great to use an OO approach instead of "magic" array keys,
e.g. like this:

https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php

While I do agree with the sentiment:

• That would have been an even greater departure from the original RFC.
• This is currently a purely procedural API. If this were about an
  hypothetical ResponseHeaders::setCookie it would definitely be the way to
  go.

why does it have to be an all or nothing approach? It's perfectly fine
to have a function that accepts an object.

We have an already accepted (29:3) RFC[1], which just lacks
implementation. Departing from the solution, which we agreed upon, in
some details (such as suggested by Pedro) might be okay, but using
objects instead of arrays is certainly not.

[1] https://wiki.php.net/rfc/same-site-cookie

--
Christoph M. Becker

Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <
mail@pmmaga.net>:

It'd be great to use an OO approach instead of "magic" array keys,
e.g. like this:

https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php

Regards, Niklas

Hi,

While I do agree with the sentiment:

• That would have been an even greater departure from the original RFC.
• This is currently a purely procedural API. If this were about an
  hypothetical ResponseHeaders::setCookie it would definitely be the way
  to
  go.

Regards,
Pedro

Hey Pedro,

why does it have to be an all or nothing approach? It's perfectly fine
to have a function that accepts an object.

Regards, Niklas

While defining SessionCookieParams object and use it is ok, but
there is a thing to consider.

How it could be more useful than current procedural API. i.e. array vs
object params.

class SessionCookiePrams {
public $lifetime;
public $path;
// and so on
}

Users still can typo with this, so it may be

class SessionCookiePrams {
private $lifetime;
private $path;
// and so on

function setLifetime() {..}
function setPath() {..}
}

Defining such OO API is out of scope for this RFC.
It would be better let users to define such OO API wrapper for the time
being.

If we would like to add OO API for session, it would be better to have
session_oo. c or like and define OO APIs in it. It requires a new RFC for
this.

One thing regarding implementation.
Since the internet RFC has only 2 values for "samesite", the parameter can
be
bool rather than string so that users can avoid "broken security by a typo".
If "samesite" has more than 2 values, the INI handler can be changed so
that it can
handle both bool and string parameters.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hi,

Last, but certainly not least, we talk about $expires here only becase
that's how it's (currently) named in either documentation and/or
reflection. But for all intents and purposes it may as well be named
$fooBar and it wouldn't matter as long as it is a concrete parameter,
whereas an associative array key name is very important. Now I'd have
to remember if it actually is "lifetime", "expire" or "expires" ... or
is it "max-age"? Not only that, but if it is either "expires" or
"max-age", I would rightfully have reasons to believe that the
expected input should be match the actual Set-Cookie attribute instead
of a PHP-specific value.
That's very unintuitive and I believe we have a general consensus on
this list that array parameters are somewhat evil. You have to
remember that the only reason we're doing this here is to avoid
parameter creep with potential for infinity, and nothing else.

Hi Andrey,

Well, "expires" is what ends up in the cookie header itself so I think that
it's simple to remember. But I do understand your arguments on semantic
purity and the fact that Max-Age is derived from it but I still believe that
in this case, it's not worth the distinction. If there ever comes a new
attribute that won't be used verbatim, what would we do? Leave it between
$expires and the options array and break all existing code? Leave it to the
end of the signature to avoid the BC break but then we are left with
something really awkward?

Look, I get it - you have your preferences and don't want to give up
on them. But now you're just speculating and aside from basically
saying "not a big deal", you haven't really addressed my arguments.

Given that we understand each other but we just disagree on what is more
important, I'd really like to hear someone else's opinion. If we are to get
something into 7.3 (which I believe we should due to
https://github.com/php/php-src/pull/2613#issuecomment-401266510) and with
the feature freeze in one week, we should reach an agreement on what to do
very soon.

Fair enough. I too would like to see more people involved in the discussion.

Although ... if the RFC is considered to be accepted (which I am still
not 100% sure if it should be, but that seems to be the case), then
technically we already have a decision made by vote. Again, I'm not
particularly happy with how it was handled, but we do have it.

Cheers,
Andrey.