These variables are now all replaced with an instance of the Superglobal
class.
The end result is that when you ask for the value of $_POST['foo'] (for
example), the value has already been passed through InputFilter for
removal of potentially malicious code.
To obtain the raw, original value of the submission, you must use a
construct that seems unnatural: $_POST->get('foo')
The intent is to make it easy to use filtered values, and to make
developers aware that they are using potentially unsafe values when they do.
It would be useful to add some other filtering to the Superglobals class
that could allow different levels of filtering. For that, some
revisions to the InputFilter class may be required.
Owen
--
Matt Read
http://mattread.com
True, though I'd strongly advise against this when writing new code,
as it essentially bypasses the protections put in place by the
SuperGlobal stuff.
See http://trac.habariproject.org/habari/changeset/2873/trunk/htdocs/system/classes/installhandler.php
for (IMO) a good example of how to properly handle this.
S
Using ArrayObject->getArrayCopy() or foreach( ArrayObject ) produces
the same result, as ArrayObject does not implement an Iterator
directly.
Rev 2887 makes SuperGlobal extend ArrayIterator instead of
ArrayObject, so the example mentioned above will use the filtered
(safe) data. Also it overloads getArrayCopy so that a filtered (safe)
array is returned (although, not recomended for consumption since it
could slow things down).
I haven't tried it, but wouldn't that affect SuperGlobal::raw()? raw()
calls $this->getArrayCopy() which would presumably trigger the now
present public method, so none of its values would actually be "raw".
Easy to fix, I think.
Owen
Yes it will. Was late and never got to implementing something.
http://trac.habariproject.org/habari/ticket/773