[split] Bug in new form validation?

CodeIgniter 3.1.7 was released today, with some changes and some bug fixes.

Changes: Updated the Cache, Email, Form Validation, Loader and Pagination libraries; deprecated the CAPTCHA helper's create_captcha() function.

Bug fixes: Database, Database Utilities, Query Builder and Session libraries; URL helper; $config['allow_get_array'] handling.

This is recommended for all users of version 3. Download v3.1.7 now, and we encourage you to read the changelog, and to check the directions for upgrading from a previous version.

Hello James,

I just came across an issue with the new Form Validation (valid_email rule) whereby I receive the following error: "Use of undefined constant INTL_IDNA_VARIANT_UTS46 - assumed 'INTL_IDNA_VARIANT_UTS46'".  Am I overlooking anything?

Thanks,
Mike

Are you using the actual 3.1.7 version, or some 3.1.7-dev snapshot?

For a while, there was a bug in the that caused this, but it was fixed and not present in the final release.

I can confirm a bug. I am getting two errors, when I am validating an e-mail address.

Code:

A PHP Error was encountered
Severity: Notice
Message: Use of undefined constant INTL_IDNA_VARIANT_UTS46 - assumed 'INTL_IDNA_VARIANT_UTS46'
Filename: libraries/Form_validation.php
Line Number: 1235

Code:

A PHP Error was encountered
Severity: Warning
Message: idn_to_ascii() expects parameter 3 to be integer, string given
Filename: libraries/Form_validation.php
Line Number: 1235

libraries/Form_validation.php

PHP Code:

/*Line 1230*/ public function valid_email($str)
/*Line 1231*/ {
/*Line 1232*/   if (function_exists('idn_to_ascii') && preg_match('#\A([^@]+)@(.+)\z#', $str, $matches))
/*Line 1233*/   {
/*Line 1234*/     $domain = is_php('5.4')
/*Line 1235*/       ? idn_to_ascii($matches[2], 0, INTL_IDNA_VARIANT_UTS46)
/*Line 1236*/       : idn_to_ascii($matches[2]);
/*Line 1237*/     $str = $matches[1].'@'.$domain;
/*Line 1238*/   }
/*Line 1239*/ 
/*Line 1240*/   return (bool) filter_var($str, FILTER_VALIDATE_EMAIL);
/*Line 1241*/ } 


An errors occuring only on one of my webhostings, so the problem could be in server configuration (I tried four different companies, localhost if also fine).

Maybe it's better to do a check like this, for those problematic servers. That for some reason have their PHP version incorrectly set up. It should be available from php 5.4.

This online tester for example don't seem to work with 5.5:
https://3v4l.org/elX65

PHP Code:

if (defined('INTL_IDNA_VARIANT_UTS46')) {
$domain = idn_to_ascii($matches[2], 0, INTL_IDNA_VARIANT_UTS46);
} else {
$domain = idn_to_ascii($matches[2]);
} 


This online tester for example don't seem to work with 5.5:
https://3v4l.org/elX65

3v4l.org simply don't have the Intl extension installed for their PHP 5.5 build: https://3v4l.org/lvVLK

You raise a good point though - in addition to no CI version being stated, both people who report the problem also don't state their PHP version ... That's bug reporting 101.

I am sorry for the poor report.

PHP 7.0.17 - problem
PHP 5.4.45 - OK
PHP 5.6.20 - OK
PHP 7.1.12 - OK
PHP 7.0.9 - OK (localhost)

I encountered this issue too, this problem may not be always related to PHP version, I have seen the problem on my customer server with PHP 5.6 version.

The INTL_IDNA_VARIANT_UTS46 constant is available in PHP 5.4.0 but the intl extension uses the ICU system lib and some servers have a really old version of the ICU lib. Support for UTS 46 Unicode IDNA Compatibility Processing was added in ICU 4.6 and released on 2010-12-02.

I was able to see in the code that you are checking if PHP version is >= 5.4 then use the INTL_IDNA_VARIANT_UTS46 constant but as stated previously if the ICU lib version is old, the INTL_IDNA_VARIANT_UTS46 may not be available.

Unfortunately, there are very bad configured and outdated servers

In most cases, this happens on hosting providers who sell shared hostings and did not fixed this issue on their side don't want to assist their customers to update the ICU lib "because it's shared hosting"

The only way I was able to resolve the issue was to extend the core form validation library (also email library) and replace the valid_email (in form validation, email library will be different) method with this one:

PHP Code:

   public function valid_email($str)
    {
        if (function_exists('idn_to_ascii') && preg_match('#\A([^@]+)@(.+)\z#', $str, $matches))
        {
            $variant = defined('INTL_IDNA_VARIANT_UTS46') ? INTL_IDNA_VARIANT_UTS46 : INTL_IDNA_VARIANT_2003;
            $str = $matches[1].'@'.idn_to_ascii($matches[2], 0, $variant);
        }
        return (bool) filter_var($str, FILTER_VALIDATE_EMAIL);
    } 


But because in PHP 7.2.0 the INTL_IDNA_VARIANT_2003 is deprecated and will be removed in future releases this code may not work in future or will thrown deprecation notices in PHP 7.2 if INTL_IDNA_VARIANT_UTS46 constant is not available.

Perhaps another workaround is available?

Hope this helps.
Regards

Yes, it looks like an ICU version problem. I checked versions on my webhostings and the problematic server have ICU version below 4.6.

PHP 7.0.17, ICU 4.2.1 - problem
PHP 5.4.45, ICU unknown - OK
PHP 5.6.20, ICU unknown - OK
PHP 7.1.12, ICU 55.1 - OK
PHP 7.0.9, ICU 4.8.1.1 - OK (localhost)

The INTL_IDNA_VARIANT_UTS46 constant is available in PHP 5.4.0 but the intl extension uses the ICU system lib and some servers have a really old version of the ICU lib. Support for UTS 46 Unicode IDNA Compatibility Processing was added in ICU 4.6 and released on 2010-12-02.

Well, shit ... You've hit the nail right on the head here.

PHP sets ICU 4.0 as a minimum requirement, even on PHP 7.2 where this practically cannot work clean without ICU 4.6. That's a horrible stalemate and they've definitely dropped the ball on this - I'll raise the issue on internals.

In the meantime we'll apply some variation of the work-around you've suggested.

Hey,

Same problem for me with PHP 5.6.33
Edit: it's the same error but for sending an email for me but look the same exact problem just the use of the Email library which has the bug

Regards,