Filter php and JInput

[Fedor Vlasenko]

Have a nice day

Tell you plan to get rid of Jinput

$input = JFactory::getApplication()->input;

$option = $input->getCmd('option', '');

->

$option = filter_input(INPUT_GET, 'option', FILTER_SANITIZE_STRING);

last code more quick-witted

I understand what data I take and as I filter

with new opportunities of PHP "sugar" in Jinput stopped being that

Thanks,

Fedor

Forgive for my language

[Mark Dexter]

That's an interesting idea. I know that JFilterInput is a bit of a mess and it would be interesting to see how much of it could be replaced using the standard PHP filter commands. Mark

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/groups/opt_out.

[Dmitry Rekun]

Mark,

Fedor is talking about dropping JInput/JInputFilter completely in favor of PHP native methods.

Dmitry

On Sunday, February 16, 2014 8:26:52 PM UTC+2, Mark Dexter wrote:

That's an interesting idea. I know that JFilterInput is a bit of a mess and it would be interesting to see how much of it could be replaced using the standard PHP filter commands. Mark

On Sun, Feb 16, 2014 at 1:39 AM, Fedor Vlasenko <vlasen...@gmail.com> wrote:

Have a nice day

Tell you plan to get rid of Jinput

$input = JFactory::getApplication()->input;

$option = $input->getCmd('option', '');

->

$option = filter_input(INPUT_GET, 'option', FILTER_SANITIZE_STRING);

last code more quick-witted

I understand what data I take and as I filter

with new opportunities of PHP "sugar" in Jinput stopped being that

Thanks,

Fedor

Forgive for my language

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Bakual]

You can't set a default value there, right?
That's imho the big advantage of Jinput.

[Viper]

Yes. If we start to use native php filters we need to set up the default values.

[Bakual]

So JInput can't be replaced directly with that as it misses important functions. There are also other things which will not work with filter_input.

However we could maybe replace JFilterInput within JInput with native PHP filter functions. This may be possible.

[Fedor Vlasenko]

With such approach
I will see this code and in 4 versions

    //Joomla framework path definitions.
    $parts = explode(DIRECTORY_SEPARATOR, JPATH_BASE);

    //Defines.
    define('JPATH_ROOT',            implode(DIRECTORY_SEPARATOR, $parts));


:-)

Thanks,
Fedor

Forgive for my language

понедельник, 17 февраля 2014 г., 10:30:44 UTC+2 пользователь Bakual написал:

[Don Gilbert]

PHP's filter_input works directly on the original input values. This means it does not support modifying $_GET or $_POST etc, which we do in JInput when parsing SEF url's to their non-SEF counterparts.

In short, filter_input could not become a suitable replacement for JInput or JFilterInput. All is not lost though, as we can potentially utilize filter_var instead, and use the same filter/sanitize flags that filter_input allows us, without the drawbacks of filter_input.

One thing of concern, however, is that PHP internals sometimes gets it wrong. In PHP < 5.3.3, FILTER_VALIDATE_EMAIL would return true when filtering 'john.doe.@gmail.com' (notice the extra dot before the @) but in later PHP versions would return false. False would be the correct response as that is strictly adherent to RFC 2822.

There's definitely a lot to consider. I would of course trust PHP core filtering and sanitizing regexes better than our own, but there will always be edge cases where we might need to provide our own implementation of a filter for security etc. Thankfully we are able to supply a custom callback to the filter_* functions by using the FILTER_CALLBACK flag and then providing our custom filter.

[Mark Dexter]

I was thinking along the lines of using filter_input inside the JFilterInput class to replace some of the "home-grown" code. That way it could be done incrementally and with less chance of b/c breaks. Mark

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Don Gilbert]

I'm not sure you read my post, Mark. I explained how we can't use filter_input, because it does not allow modifying original values.

Assume you accessed a URL like http//example.com/index.php?option=com_content&task=article.add

$app->input->get->set('task', 'add');

If you then used filter_input(INPUT_GET, 'task', FILTER_UNSAFE_RAW), it would return 'article.add', not 'add', as you would expect. Again, this is because filter_input _only_ works on the original input values, not modified $_GET values.

In short, we _cannot_ use filter_input. We can, however, use filter_var within the JFilterInput class instead.

[Fedor Vlasenko]

    $app->input->get->set('task', 'add');

it is equivalent

    $_REQUEST['task'] = 'add';

понедельник, 17 февраля 2014 г., 18:18:30 UTC+2 пользователь Don Gilbert написал:

[Don Gilbert]

Actually, $_GET['task'] = 'add' is the equivalent of what I posted. Even so, that still doesn't prove your request to use filter_input to access filtered input variables within Joomla. 

Joomla REQUIRES the ability to modify input values in order to function. filter_input never touches $_GET, $_POST etc as it uses the RAW input values from the HTTP SAPI. You cannot access modified values with filter_input. You MUST use filter_var.

[Fedor Vlasenko]

$inp = new JInput();

$inp->set('test', 100);

echo '<pre>';

echo '<h2>GET</h2>';

print_r($_GET);

echo '<h2>POST</h2>';

print_r($_POST);

echo '<h2>REQUEST</h2>';

print_r($_REQUEST);

echo '</pre>';

die;

You watch a code, you look with what you work

Where you see the data 'test'

in $_REQUEST

вторник, 18 февраля 2014 г., 0:43:16 UTC+2 пользователь Don Gilbert написал:

[Don Gilbert]

All of that is correct, but has NO bearing on nor makes any difference in the fact that filter_input does not work on modified values. It uses the RAW data from the original input from the SAPI.

Set up a local test environment if you are able. Create a script like this:

```

<?php

$_GET['var'] = 'modified_value';

echo filter_input(INPUT_GET, 'var', FILTER_UNSAFE_RAW);

```

Then, access that test script with 'var' as a GET variable, like so: http://localhost/test.php?var=123

Can you guess the output of the script? It is not 'modified_value', as you would expect. It is '123'. Again, this is because filter_input does not use the superglobals, and therefore does not work as expected when modifying $_GET, $_POST, $_REQUEST, $_SERVER or $_ENV.

We can, however, use filter_var instead.

I'm not really sure where the breakdown in communication is happening.