On Wed, Dec 3, 2008 at 10:47 AM, Sean Coates <[EMAIL PROTECTED]> wrote:
> 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.
same with adminhandler.
>> 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.
no we shouldn't. getArrayCopy is overloaded in SG to return filtered
data in case someone does use it. get_array_copy_raw() was intended to
be a protected method, but was changed to public to make it easy to
get raw data?
> 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.
agreed.
>> $_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.
most developers will be accessing handler_vars not $_POST directly. I
would like to see handler_vars link to the individual 'arrays'. like
$handler_vars->post['foo'] or $handler_vars->post->raw['foo'] which
would be the same as $_POST['foo'], $_POST->raw['foo']. and
$handler_vars->rewrite_args['foo'].
So changing to using Input class would do same thing, only provide a
global access to the handler_vars stuff.
> 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.
See comment above. getArrayCopy return filtered data, but I agree you
should avoid using it. SG class provides the map()/merge() methods
which will work like array_map/merge but give you back a new SG
object.
> 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?)
Yes, empty($_POST) is an unusual thing to do.
> 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.
++
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
