php-general Digest 21 Apr 2013 13:32:18 -0000 Issue 8203
Topics (messages 320917 through 320923):
Re: mysql_connect noob question
320917 by: Glob Design Info
320918 by: tamouse mailing lists
320921 by: Glob Design Info
320922 by: Glob Design Info
320923 by: Stuart Dallas
Re: Looking for complete entered URL
320919 by: tamouse mailing lists
320920 by: Ashley Sheridan
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Night now this is just a test server. On the real thing I'll do it right.
On 4/20/13 10:58 AM, Tedd Sperling wrote:
On Apr 20, 2013, at 11:44 AM, Stuart Dallas <stu...@3ft9.com> wrote:
On 20 Apr 2013, at 16:25, Jim Giner <jim.gi...@albanyhandball.com> wrote:
Why are you allowing anyone to connect to your database from a form?
A little OT, but...
What do you mean by this question? How do you check someone's credentials if
not by connecting to a db to verify the login? Cause I'm doing the same kind
of thing all over the place. With good practices on validation and such before
doing my query of course.
I'm pretty sure that's not what tedd meant. The code is logging in to the
database server using the username and password from the form. There are very
few legitimate reasons to be doing this, so the question is well worth asking.
-Stuart
Stuart is exactly right.
If you are checking someone's credentials to access your site, such as a user, then
giving them the "keys to the kingdom" is a bit of an overkill.
My advice, set up "user_id" and "password" fields in a "user" table for users
you want to access some portion of your site, here's the code to do that:
http://sperling.com/php/authorization/log-on.php
Where I have said "// define your user id here" is the place to actually open
your database and access your user table to gather the correct user_id and password.
I also suggest that when you open the database you only use literals from a
config.php file ($dbhost,$dbuser,$dbpass) for accessing the actual database and
then check the user_id and password before giving them authorization to private
areas.
Keep the private stuff private!
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Sat, Apr 20, 2013 at 9:37 PM, Glob Design Info <i...@globdesign.com> wrote:
> Night now this is just a test server. On the real thing I'll do it right.
>
>
> On 4/20/13 10:58 AM, Tedd Sperling wrote:
>>
>> On Apr 20, 2013, at 11:44 AM, Stuart Dallas <stu...@3ft9.com> wrote:
>>
>>> On 20 Apr 2013, at 16:25, Jim Giner <jim.gi...@albanyhandball.com> wrote:
>>>
>>>>> Why are you allowing anyone to connect to your database from a form?
>>>>>
>>>> A little OT, but...
>>>> What do you mean by this question? How do you check someone's
>>>> credentials if not by connecting to a db to verify the login? Cause I'm
>>>> doing the same kind of thing all over the place. With good practices on
>>>> validation and such before doing my query of course.
>>>
>>> I'm pretty sure that's not what tedd meant. The code is logging in to the
>>> database server using the username and password from the form. There are
>>> very few legitimate reasons to be doing this, so the question is well worth
>>> asking.
>>>
>>> -Stuart
>>
>> Stuart is exactly right.
>>
>> If you are checking someone's credentials to access your site, such as a
>> user, then giving them the "keys to the kingdom" is a bit of an overkill.
>>
>> My advice, set up "user_id" and "password" fields in a "user" table for
>> users you want to access some portion of your site, here's the code to do
>> that:
>>
>> http://sperling.com/php/authorization/log-on.php
>>
>> Where I have said "// define your user id here" is the place to actually
>> open your database and access your user table to gather the correct user_id
>> and password.
>>
>> I also suggest that when you open the database you only use literals from
>> a config.php file ($dbhost,$dbuser,$dbpass) for accessing the actual
>> database and then check the user_id and password before giving them
>> authorization to private areas.
>>
>> Keep the private stuff private!
>>
>> Cheers,
>>
>> tedd
>>
>> _____________________
>> tedd.sperl...@gmail.com
>> http://sperling.com
>>
That is a great point -- I was thinking this was a private app, but
you should never ever ever ever ever ever (x infinity) allow wild wild
web access to your database like this.
--- End Message ---
--- Begin Message ---
Thanks for that great response Geoff.
That very well may be what is wrong, however, my problem is I don't have admin
access to this server - it hosted in a BaaS site where they do all the admin.
They do provide mysql command line access and it works, but it won't let me log
in as root, not even on the command line.
Where is the '@'ip70-162-142-180.ph.ph.cox.net' part coming from? I have to
assume mysql_connect itself is appending that in the call since it's not part
of the contents of the variable I pass from the form.
And if I can't get server root access then that begs the question: how do I
tell mysql_connect to turn that off and just send the user as-is?
Thanks,
On Apr 21, 2013, at 1:42 AM, Geoff Lane <ge...@gjctech.co.uk> wrote:
> Hi,
>
> On Sunday, April 21, 2013, 3:37:38 AM, you wrote:
>
>> Night now this is just a test server. On the real thing I'll do it right.
>
> FWIW, the error you describe is one that I've seen often when setting
> up a new development/test server. In my case, the issue has arisen
> because the user doesn't have permission to connect to the database.
> This drove me nuts for a couple of days until I read the error message
> a little more carefully. In your case, you have:
>
>> *Warning*: mysql_connect() [function.mysql-connect
>> <http://localhost/wservices/function.mysql-connect>]: Access denied for
>> user '<user>'@'ip70-162-142-180.ph.ph.cox.net' (using password: YES) in
>> */Library/WebServer/Documents/wservices/connect.php* on line *29*
>
> Notice that the username isn't just 'user', but 'user@host'.
> Hopefully, you have access to the MySQL command line on the MySQL
> server. If so, log on as root then do:
>
> mysql>use mysql;
> mysql>select user,host from user;
>
> In the results table, check which hosts your user is permitted to
> connect from. Let's say for now that your results table looks like:
>
> +------------------+-----------+
> | user | host |
> +------------------+-----------+
> | root | myserver |
> | root | 127.0.0.1 |
> | debian-sys-maint | localhost |
> | root | localhost |
> +------------------+-----------+
>
> To permit a user to connect from any host, change the host value to '%'
> e.g:
> mysql>update user set host='%' where user='root' and host='myserver';
> permits user 'root' to connect from any host rather than just from
> 'myserver', the loopback IP address, and 'localhost'.
>
> If that doesn't work, you probably need to configure mysql to permit
> connections from any host. To do this, edit my.cnf (which should be
> /etc/mysql/my.cnf in Debian-based systems) and search for the line:
> bind-address = 127.0.0.1
> Comment this out and replace with:
> bind-address = 0.0.0.0
>
> Hopefully, that'll sort out the one test user you've tried so far.
> Note that you'll need to take responsibility for verifying your users
> at the application level or you'll need to create a new entry in the
> user table with CREATE USER; GRANT appropriate privileges; and then
> update the user's record to permit connection from the appropriate
> host(s).
>
> HTH,
>
> --
> Geoff Lane
> Cornwall, UK
>
--- End Message ---
--- Begin Message ---
Thanks Geoff,
I am aware of the security implications. I will deal with that later. Right now
I am just trying to get the WS architecture working.
I am logging in with the creds the hosting provider gave me (xeround.com)
When I use those creds on the mysql command line, or hard-code them in the
script, all works fine. It is only when I pass those values from my HTML form
to the script that it fails - which was why I posted the question originally -
the authentication works fine, but when entered from a form and passed to the
script it fails, which is what is so baffling.
I don't understand why mysql_connect should append something in the case of a
passed variable but not in the case of a local variable. Unless there is
something in the form parsing machinery I am unaware of.
And I am trying both from the same host.
Thanks,
On Apr 21, 2013, at 2:31 AM, Geoff Lane <ge...@gjctech.co.uk> wrote:
> Hi Glob,
>
> On Sunday, April 21, 2013, 10:46:32 AM, you wrote:
>
>> That very well may be what is wrong, however, my problem is I don't
>> have admin access to this server - it hosted in a BaaS site where
>> they do all the admin. They do provide mysql command line access and
>> it works, but it won't let me log in as root, not even on the command line.
>
> Perhaps you can issue the commands of my previous email while logged
> in as the user who's credentials they've given to you. That said, I
> wouldn't be surprised if they denied you update privs on any of the
> tables in the mysql database!
>
>> Where is the '@'ip70-162-142-180.ph.ph.cox.net' part coming from? I
>> have to assume mysql_connect itself is appending that in the call
>> since it's not part of the contents of the variable I pass from the form.
>
> I suspect that it's coming from DNS and that the MySQL instance is
> performing a reverse DNS lookup to resolve the IP address of the
> connecting host.
>
>> And if I can't get server root access then that begs the question:
>> how do I tell mysql_connect to turn that off and just send the user as-is?
>
> I don't think that you can.
>
> However, the hosting company should have given you credentials to use
> to log into the database. If your application can log in with those
> credentials, I suggest that you rewrite your code to take
> responsibility for user verification. For example, you could have your
> own user table that gives username and password together with other
> user data you need. (BTW, for security, don't store plain-text
> passwords in your database, rather store hashes (e.g. MD5) of the
> passwords and then use the appropriate function to hash the user input
> and compare with the stored hash).
>
> HTH,
>
> --
> Geoff Lane
> Cornwall, UK
>
--- End Message ---
--- Begin Message ---
On 21 Apr 2013, at 11:20, Glob Design Info <i...@globdesign.com> wrote:
> I don't understand why mysql_connect should append something in the case of a
> passed variable but not in the case of a local variable. Unless there is
> something in the form parsing machinery I am unaware of.
Nothing is being added by anything. When you log in to MySQL it takes both the
username and the IP address/hostname of the machine you're logging in from and
looks those up in the users table. This means that user abc logging in on
localhost becomes abc@localhost. User abc logging in from 192.168.0.187 becomes
abc@192.168.0.187, and is treated as a completely separate user from
abc@localhost.
The host comes from your end of the connection. So if you connect on localhost,
your end is also localhost. If you connect on the IP address or hostname, your
end is the rDNS lookup of your IP address - note that this may be the same
address as the one to which you are connecting, but will represent a different
user to @localhost as far as MySQL is concerned.
The only thing that may be being added to the variable when the form data is
parsed is slashes, and then only if you have magic_quotes_gpc switched on in
php.ini. I believe this has already been eliminated as the cause earlier in
this thread.
The problem you describe is not possible, so I'm betting your description is
missing something. Given a request with POST parameters of username=abc and
password=def, the following two lines are equivalent:
mysql_connect('localhost', 'abc', 'def');
mysql_connect('localhost', $_POST['username'], $_POST['password']);
If this is exactly what you're doing then something very strange is going on.
If this is not exactly what you're doing, please narrow your code down to the
minimum required to demonstrate the problem and post it somewhere like gist.com
then send us the link.
However, a more important question for me is why you are doing this. You say
you are aware of the security implications, and that you'll "deal with that
later," but I question how you're going to deal with it. What exactly are you
developing that requires DB credentials to come from a form on a web page?
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Sat, Apr 20, 2013 at 1:51 PM, Angela Barone
<ang...@italian-getaways.com> wrote:
> I've written a script that logs all visits to a web site, complete
> with referrer and IP address. It also logs all 4xx errors. What I'd like to
> add to this is, if someone adds extra code after the page_name.php, to be
> able to capture any extra code and log that.
>
> I've tried:
>
> $_SERVER['QUERY_STRING']
> $_SERVER['REDIRECT_QUERY_STRING']
> $_SERVER['REDIRECT_URL']
So, since I wasn't exactly sure what got put into $_SERVER, and since
I'm lazy, I tapped out the following script:
<?php
header("Content-type: text/plain");
echo '$_SERVER:'.PHP_EOL;
var_dump($_SERVER);
?>
When I called it with the following URL:
http://localhost/~tamara/teststuffout/logger.php/one/two?a=true#fragment
It showed all the stuff in $_SERVER as a result of that, including:
["REQUEST_URI"]=>
string(47) "/~tamara/teststuffout/logger.php/one/two?a=true"
["PATH_INFO"]=>
string(8) "/one/two"
["QUERY_STRING"]=>
string(6) "a=true"
Interestingly, it appears nothing reports #fragment...
--- End Message ---
--- Begin Message ---
tamouse mailing lists <tamouse.li...@gmail.com> wrote:
>On Sat, Apr 20, 2013 at 1:51 PM, Angela Barone
><ang...@italian-getaways.com> wrote:
>> I've written a script that logs all visits to a web site,
>complete with referrer and IP address. It also logs all 4xx errors.
>What I'd like to add to this is, if someone adds extra code after the
>page_name.php, to be able to capture any extra code and log that.
>>
>> I've tried:
>>
>> $_SERVER['QUERY_STRING']
>> $_SERVER['REDIRECT_QUERY_STRING']
>> $_SERVER['REDIRECT_URL']
>
>So, since I wasn't exactly sure what got put into $_SERVER, and since
>I'm lazy, I tapped out the following script:
>
><?php
>header("Content-type: text/plain");
>echo '$_SERVER:'.PHP_EOL;
>var_dump($_SERVER);
>?>
>
>When I called it with the following URL:
>
>http://localhost/~tamara/teststuffout/logger.php/one/two?a=true#fragment
>
>It showed all the stuff in $_SERVER as a result of that, including:
>
> ["REQUEST_URI"]=>
> string(47) "/~tamara/teststuffout/logger.php/one/two?a=true"
>
> ["PATH_INFO"]=>
> string(8) "/one/two"
>
> ["QUERY_STRING"]=>
> string(6) "a=true"
>
>Interestingly, it appears nothing reports #fragment...
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
It wont, the fragment is always local. You'd need javascript to handle that
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
