Hi Dan, On Tue, Jul 18, 2017 at 1:08 PM, Dan Ackroyd <dan...@basereality.com> wrote: > On 18 July 2017 at 00:22, Andreas Treichel <gmb...@gmail.com> wrote: >> Hi, >> >> i want some feedback, about the following idea before i write a rfc. >> >> ... Most of them >> are optional and extensions (e.g. same-site) make it even more messy. > > > Two thoughts: > > i) Cookie functions are easily done in userland. >
It's not that easy for somebody unfamiliar with RFC 6265, and in my observations that's most people. > ii) Adding more stuff to an already complicated thing isn't the way to > make it simple. > > Or, to repeat myself: http://news.php.net/php.internals/90940 > > >> The problem is that you're trying to build on a foundation of sand. >> The session handling works but is incredibly fragile. >> >> Or to put it more colloquially this is a "how to get to Dublin >> problem". To get to having a more secure and reliable session >> handling, we need to start from some where else, not just keep >> building on top of the current session handler code. >> >> To me, there are two good ways to proceed: >> >> i) Develop a new session extension, that doesn't depend on magic >> behaviour of globals and leave the current session handler as it is. >> The new session extension could be shipped as a 'work in progress' when >> it's good enough, before PHP 8. Then when it's stable, we could figure >> out how to transition users from the old extension. > >> ii) Develop a session handler in userland code only. PHP is powerful >> enough to support this. Although obviously there are big benefits to >> shipping a session handler with PHP, I don't see any need for it to be >> done internally other than we don't currently have a way of shipping >> userland code with an extension. I'm hoping that before PHP 8, the >> ability to ship PHP code as part of extensions would be in place. > I don't get this ... new functions are being proposed, not modifying the already existing ones - this is one of the good ways you've listed. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
