I was looking at the code and found that currently the non-mb string functions are being used: ex:

Aura\Filter\Rule\Sanitize\Strlen

if (strlen($value) < $len) {
     $subject->$field = str_pad($value, $len, $pad_string, $pad_type);
}
if (strlen($value) > $len) {
     $subject->$field = substr($value, 0, $len);
}

Here we have strlen, substr and str_pad which are non-mb safe. Which will result in various problems:

Ex. take a cyrillic script string's length - strlen("тесттест") = 16 instead of 8, so our validation will fail if we ask for strings of less than 15 characters.

An even bigger issue will ensue with the substr which may cut a unicode character in half(offtopic: slashing symbols sounds funny though) - we will get a random ascii character.

Shouldn't we instead switch to the mb functions?

Hi, my name is Satomi. I'm using aurafilter, but upon doing composer update, I updated from "2.0.0-beta2" to "2.0.0", and it seems like the "blank" validation rule went away. I'm getting this error: Aura\Filter\Exception\RuleNotMapped: blank. Did the name of this validation rule change? Thank very much!

| Q | A | | --- | --- | | Bug Fix? | yes | | New Feature? | yes | | BC Breaks? | expected | | Deprecations? | translator related | | Tests Pass? | yes | | Fixed Tickets | none | | License | Aura/MIT | | Doc PR | no |

Sent using Gush

Description

This PR was started after today's conversation on IRC, we synced with Hari and Paul to remove translator as a dependency from this component. There were some additional cleanups, moving to PSR-4, updating the readme, making the tests pass, correcting some typos on the tests, adding an autoload.php, creating a factory for the service instantiation and registry initialization and some other minor issues.

todo:

• [x] update README.md with new structure

Currently, it's acceptable to have numbers in the top level domain. Which should only be used for internationalized domains(starting with xn-- as stated in https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains

Ex. [email protected] should be invalid, but it's not.

Com1 doesn't start with xn and is not an internationalized domain either.

It's okay to be able to use an IP instead of a domain name(ex. [email protected]), but not a mix of both.

Also, as far as I know domains must be at least 2 symbols long(did a search). Hence: [email protected] should be invalid as well.

Another thing is - what about strong email validation using https://secure.php.net/manual/en/function.checkdnsrr.php

Since it makes a network call, maybe it should be in another rule, EmailMX or something.

We are currently allowing users to validate by using a string value to indicate the validator they wish to use:

$filter->validate('credit_card')->is('creditCard');

For built-in validators, we should instead use constants:

$filter->validate('credit_card')->is(Filter::CREDIT_CARD);

When working with Aura.Intl how could we get the tokens that need to be passed .

Eg :

"FILTER_RULE_FAILURE_IS_NOT_BETWEEN" => "Please do not use a value between {min} and {max}.",

The min and max , may be something like getTokens() on the RuleCollection::addMessageFromRule will help ?

array(
    'min' => $min,
    'max' => $max,
);

/ cc @cordoval

One thing I like in v2 is usage of

$email = new Aura\Filter\Email('[email protected]');
$email->isValid();

like interface. I am not sure whether this is possible currently.

But just a wishlist . The idea is usage of filters in DDD as Mathias Verras mentioned in some slides. So we don't need to inject anything to factory or use it.

Adds Filter/Sanitize for:

• caseUpper : strtoupper,
• caseLower : strtolower,
• caseTitle : ucwords,
• caseLowerFirst : lcfirst,
• caseUpperFirst : ucfirst.

All use mbstring if available.

The 'first' rules are a little odd because I think you gotta do that since there's no mb_ucfirst or mb_lcfirst.

Bugfix for missing properties(current version has no checks for such) + a new method for instead of Blank, just Null since sometimes we'd rather treat null and '' as two distinct things.

Hello @pmjones I was trying to make 'required-if' rule, where the field would be required only in some conditions, but because of the fact that rules are not called to blank fields there is no workaround about this issue.

Thanks for help George

My expectation is that isNotBlank would give me an error message if the passed in field was blank.

When I pass a field in that has a value, this validation returns an error.

Related to https://github.com/auraphp/Aura.Filter/issues/155 .

Support maximum of 2.

<?php
require __DIR__ . '/vendor/autoload.php';
$filter_factory = new \Aura\Filter\FilterFactory();
$filter = $filter_factory->newSubjectFilter();

$filter->validate('id')->is('int');
$filter->validate('url')->is('url');

$user_spec = $filter->subfilter('user'); // add a "SubSpec"
$user_filter = $user_spec->filter();  // Get the "SubSpec" SubjectFilter

$user_filter->validate('given-name')->isNotBlank();
$user_filter->validate('age')->is('int');
$user_filter->validate('gender')->is('strlen', 1);

$data = (object) [];

$result = $filter->apply($data);
$messages = $filter->getFailures()->getMessages();

var_dump($messages);

RESULT :

array(3) {
  ["id"]=>
  array(1) {
    [0]=>
    string(31) "id should have validated as int"
  }
  ["url"]=>
  array(1) {
    [0]=>
    string(32) "url should have validated as url"
  }
  ["user"]=>
  array(3) {
    ["given-name"]=>
    array(1) {
      [0]=>
      string(37) "given-name should not have been blank"
    }
    ["age"]=>
    array(1) {
      [0]=>
      string(32) "age should have validated as int"
    }
    ["gender"]=>
    array(1) {
      [0]=>
      string(41) "gender should have validated as strlen(1)"
    }
  }
}

This is related to https://github.com/auraphp/Aura.Filter/issues/117 .

As we add type definition like

public function add(string $field, string $message, array $args = array()): FailureInterface

The message is no longer a string, it can become an array when it is using subfilter .

@pmjones have forseen this

things are going to be difficult and ugly

I am still checking whether there is a way.