I got the same behavior when I did an upgrade to wp-openid 3.1.2.
The code at line 26 of openid.php is
if (!is_readable('/dev/urandom')) define( 'Auth_OpenID_RAND_SOURCE', null );
which just seems to be checking that /dev/urandom is readable, and if not it sets Auth_OpenID_RAND_SOURCE to null. The upgrade succeeds, but admin pages give that error message.
I got the same problem after update to 3.1.2
Change this:
!is_readable('/dev/urandom')
To this:
!@is_readable('/dev/urandom')
That should suppress the warning.
ahh, thanks Otto. fixed in 3.1.3 (just released)
Great job, wnorris! Thanks for supplying this hotfix 🙂
supress a warning in php, is not resolve it.
you have to put the absolute way and it’s work without a warning.
@jessai: I’m not sure I follow… what are you suggesting?
@jessai: No, that does indeed resolve it. The purpose of that line, if you look closely, is to attempt to use /dev/urandom as a source for random bits, if it’s available. If it is not available, then it uses some other source. In this case, the attempt to check to see if it is available (it’s not) also produces a worthless warning. Suppressing the warning is therefore the correct thing to do in this case.
This is what I got back from my Webhost today:
The supported method for generating strong random numbers is mcrypt_create_iv().
Is that worth looking into?
@cyberczar: not really. The idea is that the OpenID library would prefer to use a true random number generator provided by the OS. If that is not available (particularly in the case of Windows), the library automatically falls back to a pseudorandom number generator (mt_rand to be exact). This is effectively the same mechanism mt_crypt_iv() uses, so it wouldn’t make a difference.
restriction of open_basedir is for security.
You can write only in the repositary where you are or the way in poen_basedir for you :
/www/htdocs/:/tmp:/usr/bin:/bin:/usr/local/bin:/usr/share/php
you can specified an absolute way like var/www/vitual/htdocs/yourdomaine/whereyouwanttowrite/
You can write only in the repositary where
You may have noticed that this has nothing to do with “writing”, since he’s calling “is_readable()”.
open_basedir restrictions are paranoid levels security, since they don’t affect what can be written, but what can be read. The operating system should be capable of handling that stuff without overly tight open_basedir restrictions.
You can write only in the repositary where
You may have noticed that this has nothing to do with “writing”, since he’s calling “is_readable()”.
An open_basedir restriction is a basically paranoid level of security, since it doesn’t affect what can be written, but what can be opened. The operating system should be capable of handling that stuff without overly tight open_basedir restrictions.
