Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [VOTE] Same Site Cookie RFC

Posted by Frederik Bosch 
Pedro Magalhães
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 22, 2018 06:20PM
On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <[email protected]> wrote:

> 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
Niklas Keller
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 22, 2018 06:50PM
Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <[email protected]>:
>
> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <[email protected]> wrote:
>
> > 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 22, 2018 07:00PM
On 22.07.2018 at 18:40, Niklas Keller wrote:

> Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <[email protected]>:
>>
>> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <[email protected]> wrote:
>>
>>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 22, 2018 07:20PM
Am So., 22. Juli 2018 um 18:52 Uhr schrieb Christoph M. Becker
<[email protected]>:
>
> On 22.07.2018 at 18:40, Niklas Keller wrote:
>
> > Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <[email protected]>:
> >>
> >> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <[email protected]> wrote:
> >>
> >>> 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.

We can always have a second RFC that changes a previous RFC. It'll
land in PHP 7.4 then, but that's not an issue for me.

Regards, Niklas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrey Andreev
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 22, 2018 08:00PM
Hi again,

On Sun, Jul 22, 2018 at 6:47 PM, Pedro Magalhães <[email protected]> wrote:
> On Sun, Jul 22, 2018 at 1:16 PM Andrey Andreev <[email protected]> wrote:
>>
>> But while I didn't quote that part of your
>> message, you did also suggest to apply the same decision to other
>> functions and so I am talking about all of them.
>>
>> I'd be ok with this for session_set_cookie_params() alone, but not for
>> set[raw]cookie().
>
>
> I thought your comment was about session_set_cookie_params only because
> your reasoning about lifetime (as a relative amount of time) being a PHP
> construct only makes sense there.

I've been unclear about this, indeed. But I don't see why you thought
I was talking about it as a relative value in particular, nor how my
arguments would only make sense for session_set_cookie_params() ... If
anything, that's the one place where my arguments aren't as strong,
because cookie-related settings are only a small part of the session
handler.

The primary motivation for all my thoughts so far has been to follow
the IETF standards as close as possible, and (as opposed to all other
parameters) cookie attributes are *computed* from the
lifetime/expire/expires input, regardless of whether it is an absolute
or relative value. Thus, I would like for that distinction to be
obvious in the function design. That's not all of my reasoning, but
more on that below ...

> So I'm not sure why for set[raw]cookie the expires attribute would be
> treated different from the others? Max-Age is derived from it, but the value
> you pass to expires will be directly used in the cookie attribute (although
> in a different datetime format). Some other attributes are also not used
> verbatim. For instance, 'secure' being true or false also means they
> `secure;` attribute being present or omitted.
> Thinking again from the perspective of the user, I would find it annoying to
> have the expires attribute separate from the others.
>

Well, you only note the different format as a side thing, but it is
still a kind of derivation. As a side note touching on the absolute
vs. relative thing from earlier, I'd argue that if set[raw]cookie()
was designed today, it would accept a relative value (Max-Age wasn't a
thing until PHP 5.5 IIRC, so it wasn't a factor in the original
function design). Anyway ...

If semantic purity is unimportant, I could also ask why by the same
token you don't want $name and $value to be part of the array params?
How are these 2 parameters less of an inconvenience than $expires (or
whatever you call it)? We have to draw the line somewhere and it has
to be clear; turning $expires into an array key/value pair seems
arbitrary to me.

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.

And yes, Secure and HTTPonly don't go as is in the Set-Cookie header,
but those are natural edge cases that I'm sure everybody undestands.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pedro Magalhães
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 24, 2018 06:40PM
On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev <[email protected]> wrote:

> 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?

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.

Regards,
Pedro
Andrey Andreev
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 24, 2018 08:10PM
Hi,

On Tue, Jul 24, 2018 at 7:37 PM, Pedro Magalhães <[email protected]> wrote:
> On Sun, Jul 22, 2018 at 6:54 PM Andrey Andreev <[email protected]> wrote:
>>
>> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Theodore Brown
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 24, 2018 09:50PM
On Tue, Jul 24, 2018 at 11:37 AM Pedro Magalhães <[email protected]> wrote:

> 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?
>
> 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.

Have you investigated the way other languages/libraries handle this? I
developed the es-cookie module (https://github.com/theodorejb/es-cookie),
which shares the basic API of the very popular js-cookie library.

Both libraries have a `set` function with `name`, `value`, and `options`
parameters. `expires` is one of the properties that can be set in the
options object (along with `path`, `domain`, `secure`, and `sameSite`).
The `expires` property can be a number or a Date instance.

I also looked at the other most popular npm packages for cookie handling
(universal-cookie, browser-cookies, tiny-cookie, cookie_js, and more).
All of them have a set function with the same 3-parameter signature.

The benefit of this approach is that `expires` is optional, and other
attributes can be set without having to pass a value for it. I think it
would be strange and unexpected for PHP to require an `expires` value
to be passed **even if I only want to set one of the other options.**

Andrey, I understand your argument about `expires` being treated
differently from the other options, but in my opinion this isn't
sufficient reason to require a separate parameter before other attributes
can be set, or to break from the convention of existing cookie-handling
libraries that developers are familiar with.

Kind regards,
Theodore Brown
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 29, 2018 06:30AM
On Mon, Jul 23, 2018 at 10:42 AM Niklas Keller <[email protected]> wrote:

> Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <
> [email protected]>:
> >
> > On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller <[email protected]> wrote:
> >
> > > 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
Andrey Andreev
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 29, 2018 02:30PM
Hi,

On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki <[email protected]> wrote:
>
> 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.
>

The attribute has 2 possible values, but those are 2 different modes
of operation *when enabled*, not 2 states in total. It doesn't fit in
a boolean, and even if it did it wouldn't be forward-compatible that
way.

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 30, 2018 04:50AM
On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev <[email protected]> wrote:

> Hi,
>
> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki <[email protected]> wrote:
> >
> > 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.
> >
>
> The attribute has 2 possible values, but those are 2 different modes
> of operation *when enabled*, not 2 states in total. It doesn't fit in
> a boolean, and even if it did it wouldn't be forward-compatible that
> way.
>

What do you mean by "those are 2 different modes
of operation *when enabled*, not 2 states in total. "?

samesite-value = "Strict" / "Lax"

Flag is flag. It does not matter if it is used as combined values.

An INI value can be bool and string/etc. Even when 3rd value is added, it
can
be supported. Such INIs exist in PHP already.

Regards,

--

Yasuo Ohgaki
Andrey Andreev
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
July 30, 2018 12:00PM
On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki <[email protected]> wrote:
> On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev <[email protected]> wrote:
>>
>> Hi,
>>
>> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki <[email protected]> wrote:
>> >
>> > 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.
>> >
>>
>> The attribute has 2 possible values, but those are 2 different modes
>> of operation *when enabled*, not 2 states in total. It doesn't fit in
>> a boolean, and even if it did it wouldn't be forward-compatible that
>> way.
>
>
> What do you mean by "those are 2 different modes
> of operation *when enabled*, not 2 states in total. "?
>
> samesite-value = "Strict" / "Lax"
>
> Flag is flag. It does not matter if it is used as combined values.
>
> An INI value can be bool and string/etc. Even when 3rd value is added, it
> can
> be supported. Such INIs exist in PHP already.
>

A boolean makes sense for Secure and HTTPonly, where the flag either
exists or not. That's not what we have here, as SameSite=Lax is not
the same thing as not having SameSite at all.

bool(false) may make sense as an Off switch, yes, but that's not what
you suggested ...

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yasuo Ohgaki
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
August 06, 2018 11:00AM
On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev <[email protected]> wrote:

> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki <[email protected]> wrote:
> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev <[email protected]> wrote:
> >>
> >> Hi,
> >>
> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki <[email protected]>
> wrote:
> >> >
> >> > 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.
> >> >
> >>
> >> The attribute has 2 possible values, but those are 2 different modes
> >> of operation *when enabled*, not 2 states in total. It doesn't fit in
> >> a boolean, and even if it did it wouldn't be forward-compatible that
> >> way.
> >
> >
> > What do you mean by "those are 2 different modes
> > of operation *when enabled*, not 2 states in total. "?
> >
> > samesite-value = "Strict" / "Lax"
> >
> > Flag is flag. It does not matter if it is used as combined values.
> >
> > An INI value can be bool and string/etc. Even when 3rd value is added, it
> > can
> > be supported. Such INIs exist in PHP already.
> >
>
> A boolean makes sense for Secure and HTTPonly, where the flag either
> exists or not. That's not what we have here, as SameSite=Lax is not
> the same thing as not having SameSite at all.
>
> bool(false) may make sense as an Off switch, yes, but that's not what
> you suggested ...
>


Bool actually have 3 values.

true/false/null(empty)

So there isn't issue being bool INI.
It's much secure than string, since current code does not have validation.
i.e. Typo breaks security setting.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki
Re: [PHP-DEV] [VOTE] Same Site Cookie RFC
August 06, 2018 11:00AM
On Mon, Aug 6, 2018 at 5:53 PM Yasuo Ohgaki <[email protected]> wrote:

>
>
> On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev <[email protected]> wrote:
>
>> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki <[email protected]> wrote:
>> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev <[email protected]>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki <[email protected]>
>> wrote:
>> >> >
>> >> > 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.
>> >> >
>> >>
>> >> The attribute has 2 possible values, but those are 2 different modes
>> >> of operation *when enabled*, not 2 states in total. It doesn't fit in
>> >> a boolean, and even if it did it wouldn't be forward-compatible that
>> >> way.
>> >
>> >
>> > What do you mean by "those are 2 different modes
>> > of operation *when enabled*, not 2 states in total. "?
>> >
>> > samesite-value = "Strict" / "Lax"
>> >
>> > Flag is flag. It does not matter if it is used as combined values.
>> >
>> > An INI value can be bool and string/etc. Even when 3rd value is added,
>> it
>> > can
>> > be supported. Such INIs exist in PHP already.
>> >
>>
>> A boolean makes sense for Secure and HTTPonly, where the flag either
>> exists or not. That's not what we have here, as SameSite=Lax is not
>> the same thing as not having SameSite at all.
>>
>> bool(false) may make sense as an Off switch, yes, but that's not what
>> you suggested ...
>>
>
>
> Bool actually have 3 values.
>

Simple INI handler can do this, precisely.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net
Sorry, only registered users may post in this forum.

Click here to login