It sounds as if you're using the PHP HTTP module. You probably want
the HTTP_Client module instead as it has a method for doing POSTs.
In general you should use GET for HTTP requests which only solicit
information from another server and don't request that server to
change anything stored on it. For requests that change data on
another server, you should use POST.
Here is some documentation for HTTP_Client: http://pear.php.net/
manual/en/html/package.http.http-client.html
I've pretty much gotten away from sending any username/password pairs
in unencrypted http. If you send HTTPS, the header part is not
encrypted but the body is.* If you send cookies they are in the
header and thus subject to snooping, but since authentication cookies
should be only valid for a limited time, I don't think this is too
much of a problem.
I think if I were doing what you describe I would use HTTPS and put
both the un/pw and data in the body of the request, rather than
trying to send one request to get a cookie and then use that cookie
to send the actual data.
Douglas Sims
[EMAIL PROTECTED]
*er, did I state that correctly?
On Aug 16, 2006, at 4:27 PM, mos wrote:
At 09:34 AM 8/16/2006, you wrote:
Hi all,
I am working on a problem where I need to select data from my own
database, and then post it to another website (using the Get) method.
After having wasted about 4 days trying http_request, $_Get and
whatnot, I stumbled upon the header command. So far, the only way
I have been able to actually post data to the other site is
through this header command:
header (Location:"$url");
This has the drawback that the user gets to see the URL I am
sending him to, because it contains a password.
I have tried to omit 'Location', and although it doesn't generate
an error, the info also doesn't reach the intended website.
I hope there is a smarter way to have PHP perform this task,
without me actually having to reveal sensitive info to the user.
Is there anyone willing to point me in the right direction?
Kind regards,
Dirk
Dirk,
I've come up with 2 solutions. I'd try and create a
temporary cookie on the user's machine before going to the other
site, then the site can read the username/pw in the cookie. Of
course you should find some way of encrypting the cookie contents
to prevent someone from reading it. MD5()? Of course the username/
pw must exist on both webservers which could be a pain to maintain.
And of course you'd have to prevent him from re-using the cookie
later on or decoding the original username/pw etc.. So using a
cookie has a slight security risk.
You could also have your web page (webserver #1) generate a unique
random id (maybe an MD5 based on the his PHP session # or some
other unique random ID). But don't send this info to the user just
yet! Instead have your webserver #1 contact webserver #2 using
either MySQL via TCP/IP or some other 3rd party program see http://
dev.mysql.com/doc/refman/5.0/en/windows-and-ssh.html, and store
this random id in the database of webserver #2. Then and only then
redirect the user to webserver #2 with this random id in the URL.
You should of course use SSH when contacting the other MySQL server.
This tells webserver#2 to expect a user in the next 2 minutes to
allow him to connect to web server #2 if it finds this random id in
the table. After 2 minutes the id will expire. And of course after
the user connects to webserver#2, you would delete the random id
(or have it expire in 24 hours etc.-it's up to you).
Mike
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
