On Thu, May 12, 2016 at 4:13 AM, Yasuo Ohgaki 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 :)


@pierrejoye | http://www.libgd.org

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 61 of 65 | next ›
Discussion Overview
groupphp-internals @
postedMay 10, '16 at 3:25a
activeMay 12, '16 at 11:30a



site design / logo © 2019 Grokbase