This is a long thread.. replying to a few people in one go..
Chris Meller wrote:
> isset( $_POST ) would obviously never work, since $_POST is always
> set. I'd never have done that, but whoever wrote the WP importer did
> (we really need to finish those coding standard)...
Agreed: the importers are a mess. I cut my habari teeth on the s9y
importer and it really needs some love.
> In order to use any of our pseudo-arrays as actual arrays, you have
> to remember to use ->getArrayCopy() or ->get_array_copy_raw().
I'd argue that we should almost never be doing this.
> And just when you think I'm going to complain and run, here's
> another suggested approach, based a lot on the CodeIgniter and (more
> so) Kohana frameworks' implementations:
The whole point of this change (IMO) was to make it easy to audit when
authors are doing potentially dangerous things. Developers (myself
included) are morons, sometimes. I don' t think they're malicious, but
I do think they make mistakes. The idea is to make it REALLY hard for
us to make mistakes, and when we do something dangerous, it should be
easy to audit.
It's MUCH easier to grep for getArrayCopy than for a parameter
("false") that makes previously safe code potentially very dangerous.
> The basic principle here is that we don't use $_* - they're obsolete
> and can be filtered or totally unset all together. The key is that
> we don't even try to use them, thereby avoiding confusion when
> people think they know what kind of behavior to expect.
If we do decide that we can't cope with overloaded $_* superglobals,
then yes, I'd advocate unsetting them; they're just too tempting
otherwise. That said, I'd prefer to "fix" our implementation.
> As a simpler, more retro solution, we could always just filter $_*
> directly and provide some other similarly-named array that contains
> raw values. I'm not big on that approach, but it's always still an
> option.
Also possible, however, users will simply start using the full arrays,
IMO. The idea is to make them jump through hoops when they want to do
the wrong thing.
Owen Winkler wrote:
> This seems easily fixed by adding count() and empty() methods to
> SuperGlobal, creating $_POST->count() or $_POST->empty() which are
> much
> more readable:
Is there something that prevents us from implementing Countable (Matt
Read addresses this later in the thread)? There might also be a SPL
interface for empty() but nothing comes to mind.
> It also doesn't trigger the copy of the array, and doesn't need to
> intimate the intricacies of SPL (via getArrayCopy) to the novice
> coder.
1) Novice coders shouldn't be using the raw data. They're precisely
the people who are most likely to cause security problems.
2) Arrays are copied on write, so there's little to no penalty here.
> The reason we've avoided this approach is to implement security in a
> good way, abiding by the rule "Make it easier to do the right thing by
> default". The Input::foo() functions in other frameworks don't make
> it
> easier to do the right thing.
Excellent summary.
Arthus Erea wrote:
> In my opinion, Input::post($index) *is* easier than $_POST, especially
> for someone who is used to the Habari way. While outside developers
> might mess around with globals and such, Habari developers are used to
> the ***::*** format for getting something.
>
> Furthermore, the syntax does _exactly_ what we intend. It makes
> filtered the default, but makes unfiltered values possible. Overall,
> it just seems like a much cleaner approach.
True, those might be the Habari way, but what we intend here is not to
make these variables work like everything else (everything else in
Habari? or everything else in PHP? different things...). The syntax
doesn't do exactly what we need (unless we unset the super globals).
What we need is for people to not accidentally use unescaped data in
the wrong context.
Chris Meller wrote:
> I don't see what you mean here. Of course you *could* work around
> those things, but why should you have to?
There's a price to pay for better security: there's always a tradeoff
with convenience. In my opinion, this is a fair compromise.
> Again, you're drastically changing the way someone interacts with a
> classic element of the language, yet there's no concrete indication
> when you're looking at the code as to why. I see $_POST all over the
> place and expect it to work just as it always has.
I think this is your best point (-:
We should make these work as much like the intended arrays as
possible. If we can't accomplish this in what we determine is a
reasonable manner, I don't have a huge problem going to your other
method, IF:
1) The unsafe superglobal data is not available through the regular
channels (unset the superglobals)
2) code auditing the places where developers (almost always
incorrectly) pull out the unfiltered data is easy and the call is
explicit (we need to do this statically, not by adding a hook to the
method)
> $_POST['foo'] or Input::post('foo') vs. $_POST->raw('foo') or
> Input::post('foo', false)..
IF (and that's a big IF) we can't get the superglobals to work in a
reasonable manner, then I'd much rather see something like:
$_POST['foo'] or Input::post('foo') vs. $_POST->raw('foo') or
Input::raw_post('foo'). <-- MUCH easier to audit.
Matt Read wrote:
> array_* functions will not work, and casting the superglobal to array
> will return the original unfiltered array. So if you pass a
> SuperGlobal to array_* you should call getArrayCopy and such.
I don't agree here. Passing unfiltered data to (e.g.) array_map()
makes it hard to trace the output of the array_map through the current
context, thus defeating the "this data is safe" assumption.
Chris Meller wrote:
> It does work. I'm saying we shouldn't have to use count() instead of
> empty(), since that's not true of any other array (and as far as
> most people will ever know, $_POST should still be an array... they
> treat it like one 99% of the time).
I think I'd argue that empty($_POST) would fall into that 1%.
Especially with FormUI (shouldn't this check for submission,
internally?)
...
If it's not clear, I'm not ready to give up on the new superglobals
yet, however, I might be convinced if more concrete examples are shown.
S
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
