Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93258
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXa8B+4vuOiWNSt79gcSvyr2aAKv_VEbigiKTVsuaZT89g@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>
Date: Thu, 12 May 2016 08:53:23 +0700
Message-ID: <CAEZPtU7SW+yDmv_uNr_YB3MeVq_saiySaDZpF2jTOQqBzbw9Mg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
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: pierre.php@gmail.com (Pierre Joye)

On Thu, May 12, 2016 at 4:13 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Arvids,

> I don't force, but CSRF protection is optional. If you don't need it,
> don't use simply.

You actually do by using ini settings for that, or potentially force it.

Now the main issue is not about whether or not csrf is a good thing,
we all agree on that. In my opinion the questions are:

1. do we want csrf features in core?

I do not think it should. But if we decide it should then the way it
is proposed is sub optimal. CSRF usage depends strongly on the
application or request type, TTL and other behaviors as well. That
being said, that means the use of INI settings and global SESSION
array is wrong. It must be a public API.

2. if yes, does it have to be part of the session extension?

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.

I will leave this thread for now as I will going to repeat myself more
than you wish, I think we made our points clear :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org