FAQ

On May 11, 2016 1:54 PM, "Yasuo Ohgaki" wrote:
Hi Pierre,
On Wed, May 11, 2016 at 2:19 PM, Pierre Joye wrote:
On May 11, 2016 11:46 AM, "Yasuo Ohgaki" wrote:

Thank you for your comments. I've updated the RFC. You might like this
version.
I still think we should not have that in core. If we do, it should be
controlled by the application implementation and not ini settings (some
routes may have it, other not, some route may have different ttl etc).
I am
not even sure it should be part of the session module.

Sessions are per definiton easy. Implement them correctly (whatever that
means) is hard. Adding csrf to ext/session feels like adding auth
methods as
well. Both csrf ans auth may need sessions but they are not part of the
session features.
Session, authenticity, authentication cannot divide into independent
parts, but they are dependent by its nature. Whether we like it or
not, session is a part of authenticity/authentication. (I'm not going
to add authentication feature. Session's task is to store
authentication "flag", but I think authenticity is part of session)
Current session module provide authenticity partially and it could
provide good authenticity check with relatively simple change. This is
what I would like to change by this RFC.

I fully agree that implementations of proper session, authenticity,
authentication are hard. They are not simple tasks and could be
implemented badly like many applications in the wild.
We have very good userland csrf implementation provided for almost all
leading tools out there. I think this is where it should stay, userland.
If these tasks
are easy and almost all developers/applications do them correctly, I
would not bother. Unfortunately, it's not. PHP has to be provided
basic utility to web developers for the task. IMO.
Fixing education issues by adding upcoming magic quotes like feature is not
very appealing to me. Csrf is not a bad thing as mq were but the idea
described in this rfc is leading us in a very similar direction.
PHP is made for easy web application development. This RFC could
provide easy, yet good enough, CSRF protection when only POST is used.
It's just a matter of
Never been as simple for the cases I had. I see it as a rather simplistic
case used as a generic implementation system or site wise.

Csrf may need session like many other things. It does not mean it should
be part of the session extension but use it if necessary.
What is good about this RFC is applications that use only POST for
data modifications could be protected w/o single line of code
modification. And most importantly, it's easy to implement this :)
So I don't see reasons let it developers burden.
About microservices. Totally agree. The session module should care about
session management and nothing else. And for this part only, except what
has landed in recently I have a strong feeling that it is band aiding
things instead of having something modern apps could use. In short, let
stop the band aid fixes and do something better to begin with, for each
"service". Userland (already there for most) and core (outside to begin
with).

Adding so many ini settings and unrelated features won't help here, in
countrary. It will make even harder to replace it when we are so far (if
it happens ;).

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 37 of 65 | next ›
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 10, '16 at 3:25a
activeMay 12, '16 at 11:30a
posts65
users12
websitephp.net

People

Translate

site design / logo © 2019 Grokbase