php-general Digest 29 Aug 2010 21:18:18 -0000 Issue 6917
Topics (messages 307739 through 307753):
Re: Questions about $_SERVER
307739 by: Peter Lind
307740 by: tedd
307741 by: Jason Pruim
307742 by: tedd
307743 by: Per Jessen
307745 by: Peter Lind
Secure Communication?
307744 by: tedd
307746 by: Peter Lind
307747 by: Per Jessen
307748 by: Jim Lucas
307750 by: tedd
307751 by: Per Jessen
307752 by: Per Jessen
307753 by: tedd
Re: array_walk_recursive pass by reference
307749 by: Adam Richardson
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 ---
On 29 August 2010 08:08, Jim Lucas <li...@cmsws.com> wrote:
*snip*
> Their is not existing variable (if you would) that your server, when
> connecting to a remote server, would be sending. So, to have the remote end
> be able to identify the initiating host identity, the initiating side would
> have to add some something to the headers or pass it along in the body of
> the request itself.
>
+1. Let the requestion script send through identification/authentification.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
At 10:56 AM +0200 8/29/10, Peter Lind wrote:
On 29 August 2010 08:08, Jim Lucas <li...@cmsws.com> wrote:
*snip*
Their is not existing variable (if you would) that your server, when
connecting to a remote server, would be sending. So, to have the remote end
be able to identify the initiating host identity, the initiating side would
have to add some something to the headers or pass it along in the body of
the request itself.
+1. Let the requestion script send through identification/authentification.
Regards
Peter
To all:
My post about SERVER globals was simply an observation that the
SERVER global report of host and remote was not symmetric -- for
example you could obtain both the IP and Domain Name of the host, but
only the IP of the remote. Sorry for any confusion I may have caused
in my post.
As to the reason why I was asking, please review my next post, namely
"Secure Communication?"
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
On Aug 29, 2010, at 10:55 AM, tedd wrote:
At 10:56 AM +0200 8/29/10, Peter Lind wrote:
On 29 August 2010 08:08, Jim Lucas <li...@cmsws.com> wrote:
*snip*
Their is not existing variable (if you would) that your server, when
connecting to a remote server, would be sending. So, to have the
remote end
be able to identify the initiating host identity, the initiating
side would
have to add some something to the headers or pass it along in the
body of
the request itself.
+1. Let the requestion script send through identification/
authentification.
Regards
Peter
To all:
My post about SERVER globals was simply an observation that the
SERVER global report of host and remote was not symmetric -- for
example you could obtain both the IP and Domain Name of the host,
but only the IP of the remote. Sorry for any confusion I may have
caused in my post.
As to the reason why I was asking, please review my next post,
namely "Secure Communication?"
Cheers,
tedd
Hey tedd,
My understanding of how shared hosting works would make this near
impossible... Basically Apache grabs a header that is sent at the
initial connection which includes the destination hostname and from
there it translates it to the proper directory on the shared host.
All the IP's though are based off of the parent site's server...
Now with dedicated hosting where you have the entire machine you can
do what you are looking at because the IP address will always
translate back to your website.
Now hopefully my understanding of shared hosting isn't flawed but if
it is I'm sure someone will nicely point out why :)
--- End Message ---
--- Begin Message ---
At 11:54 AM -0400 8/29/10, Jason Pruim wrote:
On Aug 29, 2010, at 10:55 AM, tedd wrote:
To all:
My post about SERVER globals was simply an observation that the
SERVER global report of host and remote was not symmetric -- for
example you could obtain both the IP and Domain Name of the host,
but only the IP of the remote. Sorry for any confusion I may have
caused in my post.
Hey tedd,
My understanding of how shared hosting works would make this near
impossible... Basically Apache grabs a header that is sent at the
initial connection which includes the destination hostname and from
there it translates it to the proper directory on the shared host.
All the IP's though are based off of the parent site's server...
Now with dedicated hosting where you have the entire machine you can
do what you are looking at because the IP address will always
translate back to your website.
Now hopefully my understanding of shared hosting isn't flawed but if
it is I'm sure someone will nicely point out why :)
Your understanding is the same as my understanding.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
Jason Pruim wrote:
> My understanding of how shared hosting works would make this near
> impossible... Basically Apache grabs a header that is sent at the
> initial connection which includes the destination hostname and from
> there it translates it to the proper directory on the shared host.
>
> All the IP's though are based off of the parent site's server...
>
> Now with dedicated hosting where you have the entire machine you can
> do what you are looking at because the IP address will always
> translate back to your website.
AFAICT, Tedd was not asking about the server, he's asking about the
client.
--
Per Jessen, Zürich (17.2°C)
--- End Message ---
--- Begin Message ---
On 29 August 2010 18:04, Per Jessen <p...@computer.org> wrote:
> Jason Pruim wrote:
>
>> My understanding of how shared hosting works would make this near
>> impossible... Basically Apache grabs a header that is sent at the
>> initial connection which includes the destination hostname and from
>> there it translates it to the proper directory on the shared host.
>>
>> All the IP's though are based off of the parent site's server...
>>
>> Now with dedicated hosting where you have the entire machine you can
>> do what you are looking at because the IP address will always
>> translate back to your website.
>
The HTTP protocol does not provide a domain among the request header
fields - you need to implement idenfication/authentication in a
different manner (preferably in a way that does not rely upon IP
addresses, seeing as that doesn't provide any reliable sort of
identification).
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
Hi gangl:
I realize that the problem stated herein has been solved by others,
so I'm not claiming I've done anything new -- it's only new to me. It
was a learning experience for *me* and my solution may help others.
In any event, I've finished creating a method for establishing what I
think is secure communication between two servers. I've written two
scripts that run on different servers, which confirm communication
between them via hard-wired urls and creating/writing/reading a
url-confirmation file.
The purpose of this exercise was to simply to keep database-access
data (i.e., user_name, password, key to decryption) secret. However,
the secret could be anything you want to keep secret -- secret being
defined as no data residing on the server of concern while allowing
that server access to the data when needed and under authorization.
Here's what I've done -- I have two domains, namely webbytedd.com
(the Master) and php1.net (the Slave) -- both domains reside on
different servers. The domain names really don't matter, it's just
that this method currently works between those two domains.
Statement of Requirements:
1. The Master requires "access" to it's database.
2. The Slave keeps "access" to Master's database in it's own database.
3. It's required that "access" remain secret in the event that the
Master is hacked.
*The term "access" above is defined as database-access data, such as
user_name, password, and key to decryption.
Description of Method:
1. When the Master wants access to it's database, it first creates a
url-confirmation file and writes a token to that file, which resides
on the Master. I've used time() as the token, but the token could be
any variable -- it really doesn't make much difference other than the
value should be different each time.
2. The Master then sends a cURL request to the Slave via a POST where
the POST variable contains the token.
3. The Slave when receiving the POST request from Master reads the
token from the newly created url-confirmation file residing on the
Master and then compares that token with the token provided by the
POST -- if the tokens match, then the Slave returns "the access" to
the Master. If not, the process fails.
4. After receiving "access" the Master deletes the url-confirmation
file and continues with it operation. If the Master does not receive
"access" then it deletes the url-confirmation file and exits.
This method sounds simple enough and does several things.
1. There is no "access" stored on the Master.
2. While the Slave has "access" for the Master stored in its
database, the access to the Slave's database is kept in an
out-of-root (not open to the web) file. Note, in this case, this was
not possible on the Master because the host did not allow out-of-root
files -- but that is only tangential to the problem addressed here.
3. If a hacker did obtain access to the Slave database, then the
hacker would discover the contents have been encrypted and only the
Master has the decryption key kept in it's database.
4. If a hacker did obtain access to the code residing on the Master,
then the hacker could not access the Master's database because the
"access" data is recorded on another server (i.e., Slave).
Furthermore, the hacker could not get the code to run anywhere else
because the Slave's "look-up URL" for the url-confirmation file is
hardwired to the Master address.
5. And lastly, all communication between both domains is done via https.
Now, for the exception of both server's being hacked at the same
time, what could go wrong?
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
On 29 August 2010 18:24, tedd <t...@sperling.com> wrote:
> Hi gangl:
>
> I realize that the problem stated herein has been solved by others, so I'm
> not claiming I've done anything new -- it's only new to me. It was a
> learning experience for *me* and my solution may help others.
>
> In any event, I've finished creating a method for establishing what I think
> is secure communication between two servers. I've written two scripts that
> run on different servers, which confirm communication between them via
> hard-wired urls and creating/writing/reading a url-confirmation file.
>
> The purpose of this exercise was to simply to keep database-access data
> (i.e., user_name, password, key to decryption) secret. However, the secret
> could be anything you want to keep secret -- secret being defined as no data
> residing on the server of concern while allowing that server access to the
> data when needed and under authorization.
>
> Here's what I've done -- I have two domains, namely webbytedd.com (the
> Master) and php1.net (the Slave) -- both domains reside on different
> servers. The domain names really don't matter, it's just that this method
> currently works between those two domains.
>
> Statement of Requirements:
>
> 1. The Master requires "access" to it's database.
>
> 2. The Slave keeps "access" to Master's database in it's own database.
>
> 3. It's required that "access" remain secret in the event that the Master is
> hacked.
>
> *The term "access" above is defined as database-access data, such as
> user_name, password, and key to decryption.
>
> Description of Method:
>
> 1. When the Master wants access to it's database, it first creates a
> url-confirmation file and writes a token to that file, which resides on the
> Master. I've used time() as the token, but the token could be any variable
> -- it really doesn't make much difference other than the value should be
> different each time.
>
> 2. The Master then sends a cURL request to the Slave via a POST where the
> POST variable contains the token.
>
> 3. The Slave when receiving the POST request from Master reads the token
> from the newly created url-confirmation file residing on the Master and then
> compares that token with the token provided by the POST -- if the tokens
> match, then the Slave returns "the access" to the Master. If not, the
> process fails.
>
> 4. After receiving "access" the Master deletes the url-confirmation file and
> continues with it operation. If the Master does not receive "access" then it
> deletes the url-confirmation file and exits.
>
> This method sounds simple enough and does several things.
>
> 1. There is no "access" stored on the Master.
>
> 2. While the Slave has "access" for the Master stored in its database, the
> access to the Slave's database is kept in an out-of-root (not open to the
> web) file. Note, in this case, this was not possible on the Master because
> the host did not allow out-of-root files -- but that is only tangential to
> the problem addressed here.
>
> 3. If a hacker did obtain access to the Slave database, then the hacker
> would discover the contents have been encrypted and only the Master has the
> decryption key kept in it's database.
>
> 4. If a hacker did obtain access to the code residing on the Master, then
> the hacker could not access the Master's database because the "access" data
> is recorded on another server (i.e., Slave). Furthermore, the hacker could
> not get the code to run anywhere else because the Slave's "look-up URL" for
> the url-confirmation file is hardwired to the Master address.
>
> 5. And lastly, all communication between both domains is done via https.
>
> Now, for the exception of both server's being hacked at the same time, what
> could go wrong?
A) I wouldn't want to reinvent the wheel but would use
SSL/certificates/something to that effect (it's a whole lot more
secure than your setup), and B) there's nothing in this setup that
secures you from someone hacking Master and just sucking out data from
that machine.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
tedd wrote:
> Hi gangl:
>
> I realize that the problem stated herein has been solved by others,
> so I'm not claiming I've done anything new -- it's only new to me. It
> was a learning experience for *me* and my solution may help others.
>
> In any event, I've finished creating a method for establishing what I
> think is secure communication between two servers.
First thought - you're reinventing the wheel. When I connect to a
server via https, I have secure communication.
--
Per Jessen, Zürich (16.5°C)
--- End Message ---
--- Begin Message ---
Per Jessen wrote:
tedd wrote:
Hi gangl:
I realize that the problem stated herein has been solved by others,
so I'm not claiming I've done anything new -- it's only new to me. It
was a learning experience for *me* and my solution may help others.
In any event, I've finished creating a method for establishing what I
think is secure communication between two servers.
First thought - you're reinventing the wheel. When I connect to a
server via https, I have secure communication.
First, it isn't the connection that he is trying to secure. He admits
to using HTTPS in his connections already. What I think he is trying to
prevent (correct me if I'm wrong) is access to the data on the opposite
server. He wants to make sure that the access to this data is only able
to be done by the remote server. Hence why he said that the key to the
local data is located only on the remote server. So, my guess would be
that the key would only be usable by the remote server. It would not
work on the local server.
Jim
--- End Message ---
--- Begin Message ---
At 10:31 AM -0700 8/29/10, Jim Lucas wrote:
Per Jessen wrote:
tedd wrote:
Hi gangl:
I realize that the problem stated herein has been solved by others,
so I'm not claiming I've done anything new -- it's only new to me. It
was a learning experience for *me* and my solution may help others.
In any event, I've finished creating a method for establishing what I
think is secure communication between two servers.
First thought - you're reinventing the wheel. When I connect to a
server via https, I have secure communication.
First, it isn't the connection that he is trying to secure. He
admits to using HTTPS in his connections already. What I think he
is trying to prevent (correct me if I'm wrong) is access to the data
on the opposite server. He wants to make sure that the access to
this data is only able to be done by the remote server. Hence why
he said that the key to the local data is located only on the remote
server. So, my guess would be that the key would only be usable by
the remote server. It would not work on the local server.
Jim:
Bingo. That's it.
Sometimes it's hard for people to fully understand what I am saying
even when I explain it in great detail. Often people respond with
what they feel is an obvious solution when the statement is much more
complicated than that.
Like in this example, I use HTTPS in all the steps yet one responder
said "use HTTPS". That means: 1) He didn't understand what I was
saying; 2) He didn't read what I wrote, which probably the reason for
#1.
Also, as per another responders statement, using a SSL does not
necessarily mean that the server is more secure. In the case I am
working on the host has a SSL, but I am still going this length
because of the possibility that the server may be hacked. The SSL
only assures visitors to the host that the host is who the host
claims to be. It does not assure, nor prevent, in any way that the
server may not be hacked -- am I wrong?
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
Jim Lucas wrote:
> Per Jessen wrote:
>> tedd wrote:
>>
>>> Hi gangl:
>>>
>>> I realize that the problem stated herein has been solved by others,
>>> so I'm not claiming I've done anything new -- it's only new to me.
>>> It was a learning experience for *me* and my solution may help
>>> others.
>>>
>>> In any event, I've finished creating a method for establishing what
>>> I think is secure communication between two servers.
>>
>> First thought - you're reinventing the wheel. When I connect to a
>> server via https, I have secure communication.
>>
>
> First, it isn't the connection that he is trying to secure. He admits
> to using HTTPS in his connections already.
I didn't bother reading far enough I guess.
> What I think he is trying to prevent (correct me if I'm wrong) is
> access to the data on the opposite server. He wants to make sure that
> the access to this data is only able to be done by the remote server.
If that is the objective, it's perhaps best solved by using TLS with a
client certificate/key. Well, that's what I would do.
--
Per Jessen, Zürich (15.6°C)
--- End Message ---
--- Begin Message ---
tedd wrote:
> Like in this example, I use HTTPS in all the steps yet one responder
> said "use HTTPS". That means: 1) He didn't understand what I was
> saying; 2) He didn't read what I wrote, which probably the reason for
> #1.
You said "secure communication", which (in this context) is quite
clearly HTTP + TLS. I didn't bother reading the rest because I had
already had trouble understanding your previous questions.
> Also, as per another responders statement, using a SSL does not
> necessarily mean that the server is more secure.
Yes, it has no bearing on the security of the server, but using TLS
means the communication is. If you then also use client-side
certificates, you're really quite safe.
--
Per Jessen, Zürich (15.4°C)
--- End Message ---
--- Begin Message ---
To all:
Part of the problem in discussing security is that there are all
sorts of security issues.
There is the obvious cleaning and scrubbing of data coming into your
site from outside sources such as from POST, GET, COOKIES, and such.
There's the security problem of communication between your users and
your server, thus HTTPS and SSL's come into play.
There is the security problem in what access your users have to your
data, such as in setting directory permissions, placing files
out-of-the-root, placing data in a database and controlling users
access to such data.
And then there is the security involved in what happens *if* your
server is hacked and all your "private" data is seen by a third
party. What does all that entail -- and -- how you might be able
protect yourself should be paramount in every developer's mind.
Now, I'm not a server guy, nor do I know what happens when a server
is hacked, nor do I know what data might be exposed. I will say it
would be nice to have a server guru, like Daniel Brown, wade in on
this and tell us what is the range of things that can actually happen
and what data might be exposed and how we might protect ourselves.
At this point, I don't know the answers to those questions, but in my
readings I found that if a server is hacked, then all data contained
on the site can be read by a third party. Even encrypted data can be
decrypted *if* the keys are exposed. In addition, access to the
database can happen if the user-name and password are kept in a file,
or code, that is exposed to the hacker after hacking. Everything is
exposed.
As such, that was my recent concern and my subsequent "Secure
Communication?" post -- it was a way to protect data.
Now, how likely is it that a server might be hacked -- again, I don't
know. However, I sent numerous emails corresponding with GoDaddy.com
as to what they would do *if* their servers were hacked and their
customer's sensitive data was exposed to a third party, which caused
their customers harm.
I assumed that GoDaddy.com had insurance policies and procedures in
place to mitigate damages for their customers, but unfortunately they
responded that each case would be handled on a "We'll see" basis --
and I think we all know what that means.
So, if you want to secure your data on a server, it means that you
should take steps to do that and not rely upon the host to do that
for you. Like I said, it would be nice to have a server guru wade in
on this to clarify things.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
On Sun, Aug 29, 2010 at 12:35 AM, kranthi <kranthi...@gmail.com> wrote:
> i have an array
> $parms = array('1' => 'a', 'b' => array(3 => 'test'));
> i want $mail = '1:a 3:test';
>
But you're uppercasing and adding new lines and additional spaces, so I hope
you want (at least, this is what I tested against):
"1: A\n3: Test\n"
>
> array_walk_recursive($parms, function($val, $key, &$mail) {
> $mail .= ucwords($key) . ': '. ucwords($val) . "\n";
> }, &$mail);
>
This worked just as you said.
>
> The above function worked perfectly well
> but i am getting: Call-time pass-by-reference has been deprecated in
> /var/www/html/test.php on line 31
>
> if i change it to
>
> array_walk_recursive($parms, function($val, $key, &$mail) {
> $mail .= ucwords($key) . ': '. ucwords($val) . "\n";
> }, $mail);
>
> i am not getting the error but $mail is not being returned.
>
This failed just as you said.
Note, the function signature does not say userdata is passed by reference.
So, by the time your function is called, the original reference has already
been lost and your function is getting a reference to a copy (bummer, I
know.)
bool *array_walk_recursive* ( array &$input ,
callback<language.pseudo-types.php#language.types.callback>
$funcname [, mixed <language.pseudo-types.php#language.types.mixed>
$userdata ] )
>
> ny solution ?
>
>
For a quick fix, I'd use an object, which is pass by reference by nature:
class StringWrapper {
public $string = '';
}
$mail = new StringWrapper();
array_walk_recursive($parms, function($val, $key, $mail) {
$mail->string .= ucwords($key) . ': '. ucwords($val) . "\n";
}, $mail);
if ($mail->string == "1: A\n3: Test\n") {
echo 'Yes, this worked';
} else {
echo 'No, not again.';
}
You could also use a static method from a class and forget about passing the
$userdata variable, or use a static variable within the function itself to
maintain state.
That said, I've had several situations where I would have preferred the ease
of passing the userdata argument by reference, so I feel your pain.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
