Bug #65093 [Com]: password_hash ignores salts with spaces
Edit report at https://bugs.php.net/bug.php?id=65093&edit=1
ID: 65093
Comment by: michael at squiloople dot com
Reported by:michael at squiloople dot com
Summary:password_hash ignores salts with spaces
Status: Open
Type: Bug
Package:hash related
Operating System: Windows Vista SP2
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Would it be worth then having an error or a boolean/null return value rather
than
have it "fail" silently? If at any point the allowed characters for the salt
were
to extend then past hashes (where a salt was generated by the developer with
previously invalid characters) would be broken.
If you give the developer the option to provide a value then surely it should
be
either accepted or denied rather than just ignored.
Previous Comments:
[2013-06-22 05:48:33] r...@php.net
I think it's only a documentation problem which should explains which are the
allowed characters in the salt (from code: a-z A-Z 0-9 . /)
(notice: It is strongly recommended that you do not generate your own salt for
this function)
[2013-06-21 22:37:03] michael at squiloople dot com
Description:
When manually setting a salt which contains spaces the function ignores it and
automatically generates its own.
Test script:
---
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisisatest'));
echo '';
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
Expected result:
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
(with the part after the salt being whatever it would be)
Actual result:
--
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
--
Edit this bug report at https://bugs.php.net/bug.php?id=65093&edit=1
[PHP-BUG] Bug #65093 [NEW]: password_hash ignores salts with spaces
From: michael at squiloople dot com
Operating system: Windows Vista SP2
PHP version: 5.5.0
Package: hash related
Bug Type: Bug
Bug description:password_hash ignores salts with spaces
Description:
When manually setting a salt which contains spaces the function ignores it
and
automatically generates its own.
Test script:
---
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisisatest'));
echo '';
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
Expected result:
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
(with the part after the salt being whatever it would be)
Actual result:
--
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
--
Edit bug report at https://bugs.php.net/bug.php?id=65093&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65093&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65093&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65093&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65093&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65093&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65093&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65093&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65093&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65093&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65093&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65093&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65093&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65093&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65093&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65093&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65093&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65093&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65093&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65093&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65093&r=mysqlcfg
[PHP-BUG] Bug #65092 [NEW]: Neither errors nor result with generators and anonymous functions
From: michael at squiloople dot com
Operating system: Windows Vista SP2
PHP version: 5.5.0
Package: Arrays related
Bug Type: Bug
Bug description:Neither errors nor result with generators and anonymous
functions
Description:
When using generators with an anonymous function neither an error nor the
expected
result are shown.
Test script:
---
foreach (function ()
{
for ($i = 1; $i <= 10; ++$i)
{
yield $i => $i;
}
} as $key => $value)
{
echo $key . ': ' . $value . '';
}
Expected result:
Either:
1: 1
2: 2
3: 3
4: 4
5: 5
6: 6
7: 7
8: 8
9: 9
10: 10
Or an error of some sort.
Actual result:
--
[neither result nor error]
--
Edit bug report at https://bugs.php.net/bug.php?id=65092&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65092&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65092&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65092&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65092&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65092&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65092&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65092&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65092&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65092&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65092&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65092&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65092&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65092&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65092&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65092&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65092&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65092&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65092&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65092&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65092&r=mysqlcfg
[PHP-BUG] Bug #62041 [NEW]: Fails when recursive group comes before reference
From:
Operating system: Windows Vista
PHP version: 5.4.3
Package: PCRE related
Bug Type: Bug
Bug description:Fails when recursive group comes before reference
Description:
When the recursive subpattern is captured after it is referenced:
(?2)?::(?>((?1)(?>:(?1)){0,4}):)?
It works fine. But when the capture comes before the reference it doesn't:
((?1)(?>:(?1)){0,4})?::(?>(?2):)?
The problem is the final ":" as other characters work fine. Replacing it
with "\:"
or "[:]" does not help.
Test script:
---
// Test 1
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})(?2)?::(?>((?1)(?>:(?1)){0,4}):)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0:255.255.255.255');
// Test 2
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})((?1)(?>:(?1)){0,4})?::(?>(?2):)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0:255.255.255.255');
// Test 3
preg_match('/^(?>([a-f0-9]{1,4})(?>:(?1)){5}:|(?!(?:.*[a-f0-9]:){6,})((?1)(?>:(?1)){0,4})?::(?>(?2)!)?)(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?>\.(?3)){3}$/iD',
'0:0:0:0::0!255.255.255.255');
Expected result:
// Test 1
int(1)
// Test 2
int(1)
// Test 3
int(1)
Actual result:
--
// Test 1
int(1)
// Test 2
int(0)
// Test 3
int(1)
--
Edit bug report at https://bugs.php.net/bug.php?id=62041&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62041&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62041&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62041&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62041&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62041&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62041&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62041&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62041&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62041&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62041&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62041&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62041&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62041&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62041&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62041&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62041&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62041&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62041&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62041&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62041&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62041&r=mysqlcfg
Bug #54233 [Com]: PHP Filter email doesn't work properly
Edit report at https://bugs.php.net/bug.php?id=54233&edit=1 ID: 54233 Comment by: michael at squiloople dot com Reported by:flood at itnews-bg dot com Summary:PHP Filter email doesn't work properly Status: Open Type: Bug Package:Filter related Operating System: Slackware 13x86_64 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: That is a valid email address. "?", "'" and "_", ".", as well as letters and numbers are acceptable characters in an email address's local-part. carsten_sttgt at gmx dot de, it uses RFC 5321 (more or less). Previous Comments: [2011-03-12 12:14:02] carsten_sttgt at gmx dot de That's the correct behavior. FILTER_SANITIZE_EMAIL on: ?â?â°?âaâ¬?â?S?âaâ¬_?âaâ¬??âaâ¬Â¦?â??' this.is.a.test...@email.com results in: ???a??S?a_?a??a???'this.is.a.test...@email.com and that's a valid email address according to (at least) RFC822 (sorry, don't know which RFC PHP is exactly using for FILTER_VALIDATE_EMAIL. Should be documented) [2011-03-11 22:44:21] flood at itnews-bg dot com Hey, It seems the filter function is not working some times. You can see in the test script that the email is returned as a valid though it's not quite. [2011-03-11 22:43:36] flood at itnews-bg dot com Description: Hey, It seems the filter function is not working some times. You can see in the test script that the email is returned as a valid though it's not quite. Testing script: Test script: --- Expected result: It should return a false boolean. This is not a valid email. Actual result: -- Returns an invalid email: ???a??S?a_?a??a???'this.is.a.test...@email.com -- Edit this bug report at https://bugs.php.net/bug.php?id=54233&edit=1
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412&edit=1
ID: 52412
Comment by: michael at squiloople dot com
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Here's a request to re-open the bug, for it is indeed a bug: exceptions
can be
thrown and caught if the method called is _not_ static, as documented,
but cannot
be thrown and caught if the method _is_ static (and where the class name
is not a
variable), which is both inconsistent and against the documentation. It
is
_unexpected_ behaviour.
Previous Comments:
[2011-02-16 15:31:49] madboyka at yahoo dot com
To: der...@php.net
I don't think you've read the documentation on autoloading yourself:
http://www.php.net/manual/en/language.oop5.autoload.php
The first note states that since PHP 5.3, you may throw an exception
from the autoload function (even if the class can be loaded) and catch
that exception without a problem. Examples #3 and #4 in the
documentation entry demonstrate this. This works when the autoload
function gets invoked when instantiating a class, but doesn't when you
make a static call on it. This behavior is not consistent.
Also, take a look at michael@...'s workaround, which unexpectedly works
great. And don't tell me that PHP behaves as "expected".
I understand, that this is not a major bug, we all can live without a
fix, but at least mark it as to be fixed in the far future.
[2011-02-16 11:24:38] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
FWIW, this is "expected". The __autoload() method is the last line of
defense for PHP to find a class definition. If it can't find it, PHP
bails out with a fatal error. If you throw an exception, you basically
abort this final chance, and thus gives PHP you that fatal "can not find
class" error. However, you can catch the exception in the __autoload()
method,
--------------------
[2011-02-16 08:05:14] michael at squiloople dot com
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e->getMessage();
}
// Outputs the exception as expected.
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid "method not found" error.
getMessage(), "\n";
}
[2010-09-03 03:26:56] php dot net at phrozenbyte dot de
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52412
--
Edit this bug report at http://bugs.php.net/bug.php?id=52412&edit=1
Bug #52412 [Com]: __autoload fails to throw exception when calling a static method on the class
Edit report at http://bugs.php.net/bug.php?id=52412&edit=1
ID: 52412
Comment by: michael at squiloople dot com
Reported by:madboyka at yahoo dot com
Summary:__autoload fails to throw exception when calling a
static method on the class
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
There's a slight hack of a solution tested using PHP 5.3.5 and Windows
Vista:
use a variable as the class name:
function __autoload($class)
{
if (!include $class . '.php')
{
throw new Exception('Cannot autoload ' . $class);
}
}
$class = 'Application';
try
{
$class::start();
}
catch (Exception $e)
{
echo $e->getMessage();
}
// Outputs the exception as expected.
Previous Comments:
[2010-09-25 23:39:25] alex dot offshore at gmail dot com
Temporary solution.
Caveats and notices:
- The class actually WILL BE DEFINED ANYWAY;
- 'eval' usage;
- __callStatic used to avoid "method not found" error.
getMessage(), "\n";
}
[2010-09-03 03:26:56] php dot net at phrozenbyte dot de
Same on Ubuntu 10.04 / Apache 2.2 and CLI mode
Test script:
---
Expected result:
Exception caught
Actual result:
--
Fatal error: Class 'Foo' not found in /home/daniel/www/other/php-bug.php
on line 0
[2010-07-23 09:34:02] madboyka at yahoo dot com
Description:
I've tried to do the following:
1. Wrote and autoload method, that throws an exception.
3. Made a static call on a non-existing class within a try block.
Tried this on windows 7 / Apache 2.2 / PHP 5.3.3.
Test script:
---
http://bugs.php.net/bug.php?id=52412&edit=1
Bug #53309 [Bgs]: Capturing group failing with a colon
Edit report at http://bugs.php.net/bug.php?id=53309&edit=1
ID: 53309
User updated by:michael at squiloople dot com
Reported by:michael at squiloople dot com
Summary:Capturing group failing with a colon
Status: Bogus
Type: Bug
Package:Regexps related
Operating System: Vista
PHP Version:5.3.3
Block user comment: N
New Comment:
I don't understand. The only difference between the two cases is that
one has a
colon after the backreference and the other has a dash. Look at it like
this:
GROUP 1 :: COPY OF GROUP ONE :
GROUP 1 :: COPY OF GROUP ONE -
Why would the first fail but the second not? They should both work.
Previous Comments:
[2010-11-14 22:19:13] fel...@php.net
This is a behavior of PCRE library.
PCRE manpages says:
Like recursive subpatterns, a subroutine call is always treated
as an
atomic group. That is, once it has matched some of the subject
string,
it is never re-entered, even if it contains untried
alternatives and
there is a subsequent matching failure. Any capturing parentheses
that
are set during the subroutine call revert to their previous
values
afterwards.
[2010-11-14 16:16:33] michael at squiloople dot com
Description:
In some circumstances, when a colon is a specified character in a
capturing group,
it unexpectedly fails.
Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');
Expected result:
int(1)
int(1)
Actual result:
--
int(0)
int(1)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53309&edit=1
[PHP-BUG] Bug #53309 [NEW]: Capturing group failing with a colon
From:
Operating system: Vista
PHP version: 5.3.3
Package: Regexps related
Bug Type: Bug
Bug description:Capturing group failing with a colon
Description:
In some circumstances, when a colon is a specified character in a capturing
group,
it unexpectedly fails.
Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');
Expected result:
int(1)
int(1)
Actual result:
--
int(0)
int(1)
--
Edit bug report at http://bugs.php.net/bug.php?id=53309&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53309&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53309&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53309&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53309&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53309&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53309&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53309&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53309&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53309&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53309&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53309&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53309&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53309&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53309&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53309&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53309&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53309&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53309&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53309&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53309&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53309&r=mysqlcfg
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830&edit=1
ID: 50830
Comment by: michael at squiloople dot com
Reported by:mikerushton at hotmail dot co dot uk
Summary:FILTER_VALIDATE_IP incorrectly validates a
compressed IPv4-mapped IPv6 address
Status: Open
Type: Bug
Package:Filter related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
New Comment:
RFC 5952 is only a Proposed Standard. RFC 4291 is still the authority.
And even
if/when RFC 5952 is accepted, it is only a recommendation for (good
practice)
representation and clearly states that "all implementations must accept
and be
able to handle any legitimate RFC 4291 format".
Previous Comments:
[2010-09-07 21:42:21] sob at academ dot com
Please note that RFC 4291 has been updated by RFC 5952.
[2010-08-17 18:47:30] michael at squiloople dot com
It has come to my attention that the regular expression I provided above
uses
RFC 5321 as the authority on IPv6 address format. This differs from RFC
4291
however, which is the ACTUAL authority on IPv6 address format. The key
difference between the two is that 4291 allows a double colon to
represent just
ONE 16-bit group of zeros whereas 5321 requires that it represent at
least TWO
groups. As such, I have provided a modified regular expression which
conforms
with 4291 in this respect (and have also removed the unnecessary
capturing
groups present in my earlier regex)
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-
9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0-
9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0-
4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-
9])){3}))
[2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk
An addition: here's my solution (as a regular expression):
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](?
::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?
::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(?
:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-
5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))
[2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk
Description:
FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does
not validate the correct 0::255.255.255.255
According to RFC 5321, the correct syntax is:
[IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-
address-literal
This does not allow for three consecutive colons.
Reproduce code:
---
// First
filter_var(':::255.255.255.255', FILTER_VALIDATE_IP);
// Second
filter_var('::255.255.255.255', FILTER_VALIDATE_IP);
Expected result:
// First
bool(false)
// Second
string(21) '::255.255.255.255'
Actual result:
--
// First
string(22) ':::255.255.255.255'
// Second
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50830&edit=1
Bug #50431 [Com]: Using filter_var to filter an email address returns incorrect result
Edit report at http://bugs.php.net/bug.php?id=50431&edit=1
ID: 50431
Comment by: michael at squiloople dot com
Reported by:troy at scriptedmotion dot com
Summary:Using filter_var to filter an email address returns
incorrect result
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Ubuntu
PHP Version:5.2.11
Block user comment: N
New Comment:
The standards are actually RFC 5321 and 5322, and according to RFC 5321
(which
goes into more specific detail over domain names in email addresses),
"in the case
of a top-level domain used by itself in an email address, a single
string is used
without any dots."
Previous Comments:
[2010-05-08 02:32:01] office at lucian0308 dot com
i see a deference
the standard is http://tools.ietf.org/html/rfc2822
this function respect the standard?
because PEAR
http://pear.php.net/manual/en/package.validate.validate.email.php
say that use RFC2822 and it works corectly
without dot and level domain shoud be a false email.
[2009-12-09 19:02:01] ras...@php.net
That's a valid email address. Email addresses don't need a tld. Try
emailing r...@localhost, for example. Any locally defined host can
potentially receive email.
[2009-12-09 18:59:19] troy at scriptedmotion dot com
Description:
Using filter_var to filter a string containing an email address with no
top level domain returns the string instead of false.
For example:
filter_var('t...@1', FILTER_VALIDATE_EMAIL);
returns 't...@1' instead of false.
Reproduce code:
---
filter_var('t...@1', FILTER_VALIDATE_EMAIL); // returns 't...@1' instead of
false.
Expected result:
false
Actual result:
--
"t...@1" // a string
--
Edit this bug report at http://bugs.php.net/bug.php?id=50431&edit=1
Req #49576 [Com]: Filter var for validating email is not validating emails correctly
Edit report at http://bugs.php.net/bug.php?id=49576&edit=1
ID: 49576
Comment by: michael at squiloople dot com
Reported by:mparkin at de-facto dot com
Summary:Filter var for validating email is not validating
emails correctly
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5.*
Assigned To:rasmus
Block user comment: N
New Comment:
You might find this useful, taken directly from my article on E-mail
address
validation, in deciding whether or not to allow single-label domain
names:
"There is some confusion over whether or not single-label domain names
are
allowed â mich...@squiloople, for example. People often cite the
following
section in RFC 5321 to argue that they are not allowed:
"'Only resolvable, fully-qualified domain names (FQDNs) are permitted
when
domain names are used in SMTP. In other words, names that can be
resolved to MX
RRs or address (i.e., A or ) RRs (as discussed in Section 5) are
permitted,
as are CNAME RRs whose targets can be resolved, in turn, to MX or
address RRs.
Local nicknames or unqualified names MUST NOT be used.'
"The implicit premise here is that TLD-only domain names cannot be
resolved to
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and
getmxrr('ai',
$array) return true, showing that single-label domain names can, and do,
resolve
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain.
Therefore, mich...@squiloople is valid (although in this example,
âsquiloopleâ
is not a TLD).
"And as an extra note, hereâs another excerpt from RFC 5321:
"'In the case of a top-level domain used by itself in an email address,
a single
string is used without any dots.'"
Previous Comments:
[2010-08-15 02:09:23] paj...@php.net
Have you tried with 5.2.14 or 5.3.3?
[2010-08-14 21:10:33] grangeway at hotmail dot com
Additionally:
1) at the moment, I believe the current regex does not allow f...@com as
an
email address. Albeit, it's going back almost 10 years now - I'm pretty
sure I
received an email from someone @tld, complaining that a regex did not
allow
their valid email address to sign up.
2) The issue the user hit is the phpmailer class contains the following
code to
validate email addresses against FILTER_VALIDATE_EMAIL regardless of
whether
SMTP or mail() is the sending method.
550 public static function ValidateAddress($address) {
551if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else
regex
[2010-08-14 20:48:24] ka...@php.net
Re-opened, the last comment seems quite valid to me, don't you think so
Rasmus?
[2010-08-05 16:41:58] alexsander dot rosa at gmail dot com
The format "usern...@box" for local networks IS allowed when the mail()
method is used. I quote RFC 5321: "local aliases MUST NOT appear in any
SMTP transaction." They say NOTHING about mail() method in the RFC.
[2010-04-02 19:57:45] ras...@php.net
A much better RFC-compliant regex has been committed now.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49576
--
Edit this bug report at http://bugs.php.net/bug.php?id=49576&edit=1
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830&edit=1
ID: 50830
Comment by: michael at squiloople dot com
Reported by:mikerushton at hotmail dot co dot uk
Summary:FILTER_VALIDATE_IP incorrectly validates a
compressed IPv4-mapped IPv6 address
Status: Open
Type: Bug
Package:Filter related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
New Comment:
It has come to my attention that the regular expression I provided above
uses
RFC 5321 as the authority on IPv6 address format. This differs from RFC
4291
however, which is the ACTUAL authority on IPv6 address format. The key
difference between the two is that 4291 allows a double colon to
represent just
ONE 16-bit group of zeros whereas 5321 requires that it represent at
least TWO
groups. As such, I have provided a modified regular expression which
conforms
with 4291 in this respect (and have also removed the unnecessary
capturing
groups present in my earlier regex)
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-
9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0-
9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0-
4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-
9])){3}))
Previous Comments:
[2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk
An addition: here's my solution (as a regular expression):
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](?
::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?
::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(?
:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-
5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))
[2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk
Description:
FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does
not validate the correct 0::255.255.255.255
According to RFC 5321, the correct syntax is:
[IPv6-hex *3(":" IPv6-hex)] "::" [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-
address-literal
This does not allow for three consecutive colons.
Reproduce code:
---
// First
filter_var(':::255.255.255.255', FILTER_VALIDATE_IP);
// Second
filter_var('::255.255.255.255', FILTER_VALIDATE_IP);
Expected result:
// First
bool(false)
// Second
string(21) '::255.255.255.255'
Actual result:
--
// First
string(22) ':::255.255.255.255'
// Second
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50830&edit=1
