Wedge

It does sound familiar but by the same token...

I'm not sure I'd use it simply because I'm not sure I trust him to maintain it yet and PHP really needs a complete rebuild for PHP 6, which is not where he is going.

If you read what he has to say, though, he'd love to contribute this stuff to 5.3/5.4 but the powers that be are kicking stuff back - if I contribute a patch to something, I don't expect to have to wait a year for it to be evaluated. This did, unfortunately, happen with SMF (though it was more like 6 months rather than a year)

Yes, PHP 6 needs a fresh build and that's not where he's going, but he acknowledges that fact - it is more about raising awareness right now.

I understand that. However, a single developer, sometimes has RL issues or loses interest or whatever. If you take advantage of some of the non-compatible changes and something happens to kill development, you'll either need to take over or go back to the main PHP branch.

If he had  a core group of 2-3 people, I'd be more willing to switch since if someone gets hit by car I don't have to switch back. Maybe that is just me tho. I'm lazy.I know. I'm just saying I'm not sure it is worth the hassle if in a couple of years, PHP 6 will be what is adopted anyway.

Wow, I've been reading an it has lots of cool stuff. I'm gonna give it a go in localhost...

It looks as if $_REQUEST is disabled by default which might cause problems with "SMF since it uses that. But deep inside its bowels it declares $_REQUEST = $_GET + $_POST

And that's something I think is quite good ;)

Yeah. I have always used $_GET and $_POST prior to SMF.

Oh, well, I came from ASP Classic prior to PHP, so the REQUEST concept was nothing new. What I like is that SMF explicitly sanitises REQUEST regardless of anything else, so it honestly makes no difference for SMF or Wedge for this fork.

And what happen with SESSION?

It should be $_REQUEST = $_GET + $_POST + $_SESSION

Or maybe he is doing it on purpose to get rid of the SESSION inside the REQUEST, but why? (thinking out loud)

Um, no it shouldn't. REQUEST out of the box would normally be GET, POST and COOKIE. And therein is the reason why REQUEST is unsafe without pre filtering like SMF does.

Sorry.

You are right.

I was sorting something else involving sessions and somehow I wrote it instead of cookies. Must be the Alzheimer.

A couple of days ago, for example, playing chess with my 14 years old son, I was too concentrate defending a pawn and forgot completely to defend the queen. Lost the game, of course.  :lol:

Anyway, what I meant is why he want to get rid of the $_COOKIE inside $_REQUEST instead of sanitize it?

Even leaving only GET and POST he would need to filter it as well to avoid some attacks.

Treat the cookies in a completely separate way?

SMF ditches COOKIE from REQUEST. With good reason: minimising data taint. People who are not tech savvy invariably use REQUEST for everything. I know I did when I first came to PHP.

Consider, for a moment, the implications of using REQUEST for everything. You cannot verify the source of anything, the very first line of defence against CSRF is gone, and if you're using REQUEST rather than COOKIE you even risk adding session fixation to your vulnerability list, just for starters.

Forcing users to use GET and POST, rather than an ambiguous source is a nice step, though honestly I'd love to see a proper taint detection method such as in Perl, where you explicitly can't do anything to input without some kind of sanity check first.

I did that with my plugin, except I called it $param, because I'm used to the word param. ($param = array_merge($_GET,$_POST)).

And you're explicitly distrusting the original contents in favour of something more reliable. ;)