php-general Digest 8 Jul 2009 13:28:54 -0000 Issue 6218
Topics (messages 295004 through 295015):
Re: How to stop E_DEPRECATED messages in the PHP log?
295004 by: Jeff Weinberger
295005 by: Daniel Brown
295011 by: Andre Hübner
Re: How to authnticate and use contents from ${HOME}
295006 by: Carl Furst
Re: Simple login form with cookies
295007 by: Carl Furst
295008 by: Michael A. Peters
295009 by: Michael A. Peters
295010 by: Carl Furst
295014 by: Ashley Sheridan
295015 by: Andrew Ballard
Host that allows edit of php.ini
295012 by: Matthew Croud
295013 by: Michael Shadle
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On Jul 7, 2009, at 12:30 PM, Tom Worster wrote:
On 7/7/09 12:17 PM, "Jeff Weinberger" <[email protected]> wrote:
On Jul 7, 2009, at 8:38 AM, Daniel Brown wrote:
On Tue, Jul 7, 2009 at 11:03, Jeff
Weinberger<[email protected]> wrote:
This seemed like it would be the perfect solution...but alas it did
not
work. 22527 seems right, but after changing php.ini to that and
restarting
php and apache, I am still getting "Deprecated..." messages.
Dumb question, Jeff: are you sure you're editing the correct
php.ini file?
--
</Daniel P. Brown>
[email protected] || [email protected]
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at
http://twitter.com/pilotpig
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Daniel:
Not a dumb question at all! I check every time (php_info()) to make
sure the "loaded configuration file" is the one I'm editing. So, as
far as I can tell, yes.
Should I be looking at something else to be sure?
i've now had a look at http://www.php.net/manual/en/errorfunc.constants.php
in your shoes i'd try out 2047 (with is everything up to and including
E_USER_NOTICE) and possibly 6143 (=2047+4096) if you have your own
error
handler.
if still no luck i can't think of anything else to suggest but work
backwards:
check the value returned by error_reporting() is the value you set in
php.ini.
binary decode it to double check.
if it sill makes no sense, check the php bugs db. and if nothing,
maybe
report it.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Tom:
thanks - I'll try those and report back, and will keep playing with
various combinations until I get it to work or prove it doesn't :)
One question - that I for some reason have not found - is there a list
of the numerical values of the E_* constants somewhere?
Thanks for your help!
--Jeff
Real love is a pilgrimage. It happens when there is no strategy, but it is very
rare because most people are strategists. -Anita Brookner
--- End Message ---
--- Begin Message ---
On Tue, Jul 7, 2009 at 17:46, Jeff Weinberger<[email protected]> wrote:
>
> One question - that I for some reason have not found - is there a list of
> the numerical values of the E_* constants somewhere?
You bet: http://php.net/manual/en/errorfunc.constants.php
--
</Daniel P. Brown>
[email protected] || [email protected]
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at
http://twitter.com/pilotpig
--- End Message ---
--- Begin Message ---
Hello,
Try
error_reporting(E_ALL ^ E_DEPRECATED);
Thanks for your suggestion - it would work nicely, except that that is
a runtime function that is called within a script.
but if it works within script you could do it by auto_prepend_file to stop
flooding the log until solution is found...
i start packaging 5.3 next days so it is also interesting for me and my
"deprecated" users.
unfortunately no 5.3 experience until now...
Andre
--- End Message ---
--- Begin Message ---
PHP may not be the thing to do this.. because it sounds like you want
the users to chroot to ${HOME} which php especially on a vhost does not do.
If you want users to access an nfs or ftp I would use either samba or
vsftp or some other scp/ftp software.
Jan G.B. wrote:
> 2009/7/6 Isaac Dover <[email protected]>
>
>
>> Hi Chantale, as Bastien mentioned, a preconfigured package might be the
>> best
>> way to go. Wikipedia has more information:
>>
>> http://en.wikipedia.org/wiki/List_of_LAMP_Packages
>>
>> What are you wanting to build in your interface?
>>
>> - Isaac
>>
>> On Mon, Jul 6, 2009 at 9:14 AM, Bastien Koert <[email protected]> wrote:
>>
>>
>>> Try xamp or one of the preconfigured packages
>>>
>>> bastien
>>>
>>> On Sunday, July 5, 2009, <[email protected]> wrote:
>>>
>>>> Hello,
>>>>
>>>> My name ich Chantale, I am 15years old and in a german Lycee. I like to
>>>>
>>> study Informatic in two years and now try to code my first applications.
>>>
>> I
>>
>>> am new to php and like to code my own Intranet Web-Interface which should
>>> run on my FileServer at home.
>>>
>>>> I have installed suPHP, but it seems to be not the thing I need,
>>>>
>> because
>>
>>> it works only on a VHost.
>>>
>>>> What I need is, that a ${USER} can login and work on her/his ${HOME}.
>>>>
>>>> How can I archive this?
>>>>
>>>> Thank you
>>>> Chantale
>>>>
>>>>
>>>>
>
>
>
> Installing LAMP is not a good idea for productive servers. Always stick with
> the Packages of your distribution to get all upgrades.
> Activating a module isn't hard at all, so... there's not really a need for
> packages like "LAMP" on a unix-like OS.
> The point in not using such Packages like LAMP on a system which isn't
> productive is learning to set up a productive server. You decide.
>
> mod_auth_pam might be a way fo accomplish what you want.
>
> Just my two cent.
>
>
--- End Message ---
--- Begin Message ---
The basic model for password authentication is to use one way crypt
routines. MySql has several, PHP also has them. The basic algorithm
would be like this:
1) read the password from the form.
2) read the password from you datastore that matches the user name or
session
3) encrypt the password on the form.
4) do a string comparison between the database data and the encrypted
password from the form.
This is of course assumes that you have been encrypting your password
when you store them (always good practice) so I think this translates to
php as (forgive me if this is bogus, it's been a while since I've done
any php)
<?
$salt = 'someglobalsaltstring'; # the salt should be the same salt used
when storing passwords to your database otherwise it won't work
$passwd = crypt($_GET['passwd'], $salt);
if ($passwd == $userObject->getPassword) { return 1} else {return 0}
?>
So I've not tested this obviously but you would have to have a
$userObject which is your interface between your software and your user
data.
Hope it helps,
Carl.
PJ wrote:
> PJ wrote:
>
>> Jason Carson wrote:
>>
>>
>>>> On Mon, Jul 6, 2009 at 02:19, Jason Carson<[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>> ok, I have two sets of scripts here. One uses setcookie() for logging
>>>>> into
>>>>> the admin panel and the other uses session_start(). Both are working
>>>>> fine,
>>>>> is one more secure than the other?
>>>>>
>>>>>
>>>>>
>>>> $_COOKIE data is written to a file that is readable/writeable and
>>>> stored on the user's side of things. $_SESSION data is written to the
>>>> server, with a cookie stored on the user's side containing just the
>>>> PHPSESSID (session ID) string to identify the session file on the
>>>> server.
>>>>
>>>> So determining which is better and/or more secure is really a
>>>> matter of the data held there and how it's handled. If storing things
>>>> like usernames or you absolutely want to store personal data in an
>>>> active session, do so in $_SESSION. If you're storing a password or
>>>> credit card number in the active session, you may as well do it in
>>>> $_COOKIE, because you're already using an insecure model. ;-P
>>>>
>>>> --
>>>> </Daniel P. Brown>
>>>> [email protected] || [email protected]
>>>> http://www.parasane.net/ || http://www.pilotpig.net/
>>>> Check out our great hosting and dedicated server deals at
>>>> http://twitter.com/pilotpig
>>>>
>>>> --
>>>> PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Well I'm a newbie when it comes to PHP and programming. I guess I need to
>>> read up on login security. Do you know of, or recommend, any websites that
>>> will show me how to secure my login model (Using cookies or sessions).
>>>
>>>
>>>
>>>
>> Hi Jason,
>> I'm probably not any wiser than you, but I have just (today) discovered
>> an interesting site that seems to have some really clear explanations
>> and tutorials re php, MySsql et al.
>> It's worth looking at (I'm trying to implement something like what you
>> are, as well):
>> http://www.brainbell.com/tutors/php/php_mysql/Authorizing_User_Access.html
>> HTH,
>> PJ
>>
>>
>>
> I just found another site which is easier to deal with (chapter
> references) and seems to be the original source of the brainbell site:
> http://home.bolink.org/ebooks/webP/webdb/index.htm
>
>
--- End Message ---
--- Begin Message ---
Carl Furst wrote:
The basic model for password authentication is to use one way crypt
routines. MySql has several, PHP also has them. The basic algorithm
would be like this:
1) read the password from the form.
2) read the password from you datastore that matches the user name or
session
3) encrypt the password on the form.
4) do a string comparison between the database data and the encrypted
password from the form.
Read the password on the form.
Encrypt the password on the form using same salt and algorythm you use
to generate the hash.
Then -
$sql = "SELECT id FROM userdb WHERE user='$user' AND pass='$pass'";
If your query returns a result, you now have a user id to store in the
session. Otherwise, the login fails.
No need to read from the database and do a string compare.
Of course you need to watch out for injection when doing it that way,
but that's what prepared statements are for.
--- End Message ---
--- Begin Message ---
Carl Furst wrote:
<?
$salt = 'someglobalsaltstring'; # the salt should be the same salt used
when storing passwords to your database otherwise it won't work
$passwd = crypt($_GET['passwd'], $salt);
I personally use the username and the salt.
That way two users with identical passwords have different hashes.
With large databases, many users will have the same password, there are
some that are just commonly used. The hackers know what they are, and if
they get your hash dump, they try their list of commonly used passwords
against the user names that have the common hashes.
By using the username as part of the salt, you avoid that issue because
identical passwords will have different hashes.
It does mean the password has to be reset if you allow them to change
their login name.
--- End Message ---
--- Begin Message ---
These are great ideas.
Another option would be to have the user choose a pin number and use
either the literal pin or the encrypted pin as part of the salt. This
way only when you change the pin do you need to change the password,
which is probably what you would want anyway.
Michael A. Peters wrote:
> Carl Furst wrote:
>
>>
>> <?
>> $salt = 'someglobalsaltstring'; # the salt should be the same salt used
>> when storing passwords to your database otherwise it won't work
>> $passwd = crypt($_GET['passwd'], $salt);
>
> I personally use the username and the salt.
> That way two users with identical passwords have different hashes.
>
> With large databases, many users will have the same password, there
> are some that are just commonly used. The hackers know what they are,
> and if they get your hash dump, they try their list of commonly used
> passwords against the user names that have the common hashes.
>
> By using the username as part of the salt, you avoid that issue
> because identical passwords will have different hashes.
>
> It does mean the password has to be reset if you allow them to change
> their login name.
>
>
--- End Message ---
--- Begin Message ---
On Wednesday 08 July 2009 04:25:46 Carl Furst wrote:
> These are great ideas.
>
> Another option would be to have the user choose a pin number and use
> either the literal pin or the encrypted pin as part of the salt. This
> way only when you change the pin do you need to change the password,
> which is probably what you would want anyway.
>
> Michael A. Peters wrote:
> > Carl Furst wrote:
> >> <?
> >> $salt = 'someglobalsaltstring'; # the salt should be the same salt used
> >> when storing passwords to your database otherwise it won't work
> >> $passwd = crypt($_GET['passwd'], $salt);
> >
> > I personally use the username and the salt.
> > That way two users with identical passwords have different hashes.
> >
> > With large databases, many users will have the same password, there
> > are some that are just commonly used. The hackers know what they are,
> > and if they get your hash dump, they try their list of commonly used
> > passwords against the user names that have the common hashes.
> >
> > By using the username as part of the salt, you avoid that issue
> > because identical passwords will have different hashes.
> >
> > It does mean the password has to be reset if you allow them to change
> > their login name.
and then make a visit to their house to give them a secondary password that
they have to use. Make sure you're not tailed on the way to avoid the
password being intercepted...
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Tue, Jul 7, 2009 at 11:05 PM, Michael A. Peters<[email protected]> wrote:
> Carl Furst wrote:
>
>>
>> <?
>> $salt = 'someglobalsaltstring'; # the salt should be the same salt used
>> when storing passwords to your database otherwise it won't work
>> $passwd = crypt($_GET['passwd'], $salt);
>
> I personally use the username and the salt.
> That way two users with identical passwords have different hashes.
>
> With large databases, many users will have the same password, there are some
> that are just commonly used. The hackers know what they are, and if they get
> your hash dump, they try their list of commonly used passwords against the
> user names that have the common hashes.
>
> By using the username as part of the salt, you avoid that issue because
> identical passwords will have different hashes.
>
> It does mean the password has to be reset if you allow them to change their
> login name.
>
The password does not need to be reset. You could require that they
provide the password again (even though they are already
authenticated) on the same form with the new username. Then you can do
the same encrypt/compare that you do for authentication, and if it
matches you just update the username and the hash at the same time.
Andrew
--- End Message ---
--- Begin Message ---
Apologies if this type of question is frowned upon in the mailing list,
however I would like to pop the question to those in the know.
Can anyone recommend a UK host that allows you to edit ( or a copy
of ) the php.ini file,
allowing me to increase the file upload size to 100mb for clients PDF
artwork files.
I wish to create an upload site for my print firm.
Your recommendations are greatly appreciated.
Matt.
--- End Message ---
--- Begin Message ---
Someone who adopts php 5.3.0 or uses htscanner might allow for it. I'm
too lazy to check if memory limit is allowed on an htscanner/htaccess
level or not
On Wed, Jul 8, 2009 at 1:27 AM, Matthew Croud<[email protected]> wrote:
> Apologies if this type of question is frowned upon in the mailing list,
> however I would like to pop the question to those in the know.
>
> Can anyone recommend a UK host that allows you to edit ( or a copy of ) the
> php.ini file,
> allowing me to increase the file upload size to 100mb for clients PDF
> artwork files.
> I wish to create an upload site for my print firm.
>
> Your recommendations are greatly appreciated.
>
> Matt.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
