Yes, but I think it is more of a style issue than substance.PCSpectra wrote:Arborint, do you still feel this way, years later?
Something good written with the Zend Framework
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Something good written with the Zend Framework
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Something good written with the Zend Framework
I have thought about this for a while now and I think I have myself more confused than before...
How does forcing the request object to return only GET or POST data (based on the actual request method (GET or POST) enhance security? I suppose I like the explicit-ness of it but does it really matter where the data comes from when using $_REQUEST as a array as opposed to GET or POST explcitly?
Iinitially I thought it might prevent CSRF but after some more thought I don't think this is the case, is it???
Cheers,
Alex
How does forcing the request object to return only GET or POST data (based on the actual request method (GET or POST) enhance security? I suppose I like the explicit-ness of it but does it really matter where the data comes from when using $_REQUEST as a array as opposed to GET or POST explcitly?
Iinitially I thought it might prevent CSRF but after some more thought I don't think this is the case, is it???
Cheers,
Alex
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Something good written with the Zend Framework
The problem with $_REQUEST is that data expected from one source could be overwritten by another. A request object that provides data from the appropriate array based on the request type is a different thing. You should still do isPost/isGet checks as necessary, and more importantly filter and escape incoming data.
(#10850)
Re: Something good written with the Zend Framework
The reason you have a request object is specifically so you de-couple from super globals. Later on you could subclass the request object for testing. You could subclass the request object to return named CLI arguments (I think this is already in the Zend "core" actually). You could even get clever and sub-class the request object on a per-module basis, using it like a value object to remove "feature envy"