Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93260
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU7SW+yDmv_uNr_YB3MeVq_saiySaDZpF2jTOQqBzbw9Mg@mail.gmail.com>
References: <CAGa2bXZytbD1H-Rg5eWfiPwEM0p47JSQH-GC-ZayDSLbmbsGVA@mail.gmail.com>
 <c21d1d4b-a790-e1a9-7c93-2c5af4baf5d1@gmail.com> <CAGa2bXboop3KDFnYtcdO-K+hL0To5te_yeHeFEFO-kCVuzNOJQ@mail.gmail.com>
 <3b115b37-d399-0b69-24b4-de5c95c4a069@gmail.com> <CAGa2bXZwRK0GuXbT53B4w+h5ySiVJnJpo-d87Uiw-reYHi80zQ@mail.gmail.com>
 <CANUQDChxOeydBRLPrvuumf+edqJNKV+TOstGz66X_tg+Y7knPQ@mail.gmail.com>
 <CAGa2bXZC8Qp8-Ggyfj5+0X5aiktSX_AyfRdKAPXFZ=x4+A1XDQ@mail.gmail.com>
 <CANUQDCgi-P4=rWA5H+53_BcWyqeWaC_QOADUNMb_jV70KuhEPw@mail.gmail.com>
 <CAL0xaBFTF28h7ZTCkk=gn2=kepv0xe_Gk0+zjhmZzDmLJYU3-w@mail.gmail.com>
 <CAGa2bXbX_YhpJEr+9XjTb3xxgb2KTw=LEjC97A0vM4_WNiSvnA@mail.gmail.com>
 <CAL0xaBF8e7PhY_hqNYwNvxwRiha1=rUtLBfugUNC2FGf2FndzA@mail.gmail.com>
 <CAGa2bXa8B+4vuOiWNSt79gcSvyr2aAKv_VEbigiKTVsuaZT89g@mail.gmail.com> <CAEZPtU7SW+yDmv_uNr_YB3MeVq_saiySaDZpF2jTOQqBzbw9Mg@mail.gmail.com>
Date: Thu, 12 May 2016 12:19:18 +0900
Message-ID: <CAGa2bXbwJHRES6Bf+u07pO2e9WS6C+sTwjoY9p8kWAUntSLbCQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Niklas Keller <me@kelunik.com>, 
	Stanislav Malyshev <smalyshev@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Pierre,

On Thu, May 12, 2016 at 10:53 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> My answer is clearly no. We must rather simplified improved the
> session implementations and APIs, focusing purely on its core
> purposes, managing session data storage and provides interfaces&APIs
> to match application needs. We do not do that very well anymore.

We did not do very well for a long time, indeed.

Session manager must not accept uninitialized session ID. It's obvious
mandatory requirement for decent session manager, but it took me many
years to add it and it's not enabled by default yet. I think a decade
has passed since strict session was proposed.

Another mandatory feature that time stamp based session data
management is taking years and I'm not sure if I can add this for PHP
7.1.

Even simple mandatory API for house keeping task like session_gc() is
taking many years to be implemented.

It could be an option that abandon session module and let users to
implement decent session manager because we are taking too long time
even for mandatory things even if there are implementations. It is
simply taking too long time to fix them. I'm half joking, but half
serious :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net