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

[Yasuo Ohgaki]

On Mon, Jul 23, 2018 at 10:42 AM Niklas Keller  wrote:

> Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães <
> m...@pmmaga.net>:
> >
> > On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller  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
yohg...@ohgaki.net

[PHP-DEV] Re: apache2 buckets API masters needed

[Stanislav Malyshev]

Hi!

> I need help from somebody who knows how to deal with the details of
> Apache2 bucket brigade API for some issue in Apache2 SAPI. I suspect
> there's a bug there that can lead to serious problems in certain
> situations but not sure how to fix it because my knowledge of proper
> ways to handle Apache2 buckets is limited. The details are in
> https://bugs.php.net/bug.php?id=76582 - if you don't have access to it,
> please tell me and I'll enable it or send you the details.

Didn't get any substantial response on this in two weeks, so I wonder -
is anybody still actively maintaining our Apache2 extension? It's not a
good situation where interface for one of the most frequently deployed
servers does not have anybody taking care of it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Status of ci.qa.php.net?

[Ferenc Kovacs]

On Thu, Jul 26, 2018 at 11:34 AM, Christoph M. Becker 
wrote:

> Hi!
>
>  refers to , but the latter
> appears to be unavailable.  It seems the site was about Jenkins CI – has
> it been superseeded by Travis and Appveyor?  If so, qa.php.net should be
> updated.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

it was mostly managed and used by me and at one point it went down and I
did not had the time to contact the provider and figure out what happened.
I'm fine with being removed or if you think that it would be useful we can
try bringing it back.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu