Httpobject
by Wolfgang Kurz · in Torque Game Engine · 11/18/2006 (3:24 pm) · 15 replies
Hello all
i have a little problem with getting HttpObject to work
what i have is this:
and on the site i have a php page just doing this:
but the function on line is never called:-(
so i was wondering if anyone could help me solve this please
i have a little problem with getting HttpObject to work
what i have is this:
$AuthServer = "www.myspace.com:80";
function DoLogin(%Name, %PW){
checkClientLogin(%Name, %PW);
%this.loginLoop = schedule(3000, 0, "LoginFailed" );
}
function checkClientLogin(%username, %passcrc){
%server = $AuthServer;
%script = "index.php";
%udp = new HTTPObject(CharLogin);
%udp.clientid = %client;
%udp.get(%server, %script, "");
}
function CharLogin::onLine(%this, %line){
echo("%line"@"nap");
if(strstr(%line, "Verified") != -1){
%this.cancle(loginLoop);
return;
}
//login failed
error("- ",%line);
return;
}
function LoginFailed(){
echo("Login failed!");
}and on the site i have a php page just doing this:
echo"hello"; echo"";
but the function on line is never called:-(
so i was wondering if anyone could help me solve this please
#2
fixed the things you mentioned but those couldnt be the problem
the function should have at least been called
yes on www.myspace.com there is a file called index.php
if i call the page in a browser it just prints "hello" like the code i showed above
11/19/2006 (2:54 am)
Thx for the responsefixed the things you mentioned but those couldnt be the problem
the function should have at least been called
yes on www.myspace.com there is a file called index.php
if i call the page in a browser it just prints "hello" like the code i showed above
#3
Now, some theories on my part which may be wrong since I'm not up on my HTTPObject stuff. Depending on the webserver configuration, a 404 error may not return any content at all, only HTTP headers. If your HOSTS file or proxy is screwing things up and redirecting myspace.com somewhere, you would see your page, whereas I'm not sure TGE uses HOSTS and attempts to call the address directly; if this is the case this would explain why onLine is never being called since there is no line ever received for this 404. Maybe. Who knows.
But again, let's make this clear, there is no index.php on www.myspace.com, unless you work there or have hacked their servers :)
11/19/2006 (6:17 pm)
Please post your updated code. Also, you may want to check your HOSTS file for www.myspace.com. Myspace runs Coldfusion (Fusebox framework, to be exact) which are .cfm files. They do not run PHP. Besides that, there is no way you could have uploaded your own script to Myspace.com, unless you work there and have installed PHP on their servers, which is not the case: http://www.myspace.com/index.php returns a 404 for me.Now, some theories on my part which may be wrong since I'm not up on my HTTPObject stuff. Depending on the webserver configuration, a 404 error may not return any content at all, only HTTP headers. If your HOSTS file or proxy is screwing things up and redirecting myspace.com somewhere, you would see your page, whereas I'm not sure TGE uses HOSTS and attempts to call the address directly; if this is the case this would explain why onLine is never being called since there is no line ever received for this 404. Maybe. Who knows.
But again, let's make this clear, there is no index.php on www.myspace.com, unless you work there or have hacked their servers :)
#4
Yeah post your updated code and lets go from there.
11/19/2006 (6:58 pm)
I don't think he means "myspace.com" in literal since. He's just using that to mask his actual address.Yeah post your updated code and lets go from there.
#5
Actually... hrm hrm, correct me if I'm wrong, but don't you need a / before the path to the script? I just noticed it in some old code I had written when I was first messing with HTTPObject (details changed):
11/19/2006 (10:51 pm)
Hey, I was just making sure :D Seemed the next-most-obvious thing without updated code.Actually... hrm hrm, correct me if I'm wrong, but don't you need a / before the path to the script? I just noticed it in some old code I had written when I was first messing with HTTPObject (details changed):
$HTTPHost="www.myserver.com:80";
$HTTPPath="/this/was/mypath/"; [b]Note the leading /[/b]
function seeOutsideWorld ()
{
// Is this working?
%server = $HTTPHost;
%path = $HTTPPath;
%httpCheck = %path @ "helloworld.aspx";
%poons = new HTTPObject(helloWorld);
%poons.get(%server, %httpCheck, "");
}
#6
it was the missing slash:-) well that and that it took the server for ever to response
thats when i had this:
echo"hello";
echo"
";
when i did this:
echo"hello\n";
echo"
";
the server would response right away
well thx again:-)
and ya i didnt mean myspace literaly:-)
11/20/2006 (1:19 am)
Thx a lot guys:-)it was the missing slash:-) well that and that it took the server for ever to response
thats when i had this:
echo"hello";
echo"
";
when i did this:
echo"hello\n";
echo"
";
the server would response right away
well thx again:-)
and ya i didnt mean myspace literaly:-)
#7
since it worked now i thougth hey cool i can send things to the page now
so i would use the %qurey parameter like this: (i tried a few ways:)
%query = "user=hello\t" @ "passw=passw\n";
%query = "user=hello&passw=passw"
and so on
if i use only one variable it works no problem but if i use two like oyu see above it writes both values into the first variable
in my php script i get the variables like this:
$user = $GET['user'];
$passw = $GET['passw'];
anyone know what i am doing wrong again?
11/22/2006 (12:40 am)
Sorry i bumped into another problem i cant figure outsince it worked now i thougth hey cool i can send things to the page now
so i would use the %qurey parameter like this: (i tried a few ways:)
%query = "user=hello\t" @ "passw=passw\n";
%query = "user=hello&passw=passw"
and so on
if i use only one variable it works no problem but if i use two like oyu see above it writes both values into the first variable
in my php script i get the variables like this:
$user = $GET['user'];
$passw = $GET['passw'];
anyone know what i am doing wrong again?
#8
Passing the passwords in plaintext through URL strings is kind of an insecure way to do it, BTW, and POSTing it isn't much better, but let's get your thing working first then talk about alternatives.
11/25/2006 (10:34 am)
Can you give us your code, how you're calling this? Are you tacking these into the script URL? And, if so, can you give us what your PHP script is seeing? Your ampersand may be getting url encoded that could screw it up, or something to that effect. Passing the passwords in plaintext through URL strings is kind of an insecure way to do it, BTW, and POSTing it isn't much better, but let's get your thing working first then talk about alternatives.
#9
my biggest problem is that i cant decode the string before i call $_REQUEST or $_GET
the way i do it right now is that i call REQUEST which puts the whole string in the first variable
and then i decode it and parse the string then myself
i was just wondering if there is a easier method?
and whats that about security you are saying?:-)
11/27/2006 (1:08 am)
Well the problem is indeed that the string gets encoded and the & signs get replacedmy biggest problem is that i cant decode the string before i call $_REQUEST or $_GET
the way i do it right now is that i call REQUEST which puts the whole string in the first variable
and then i decode it and parse the string then myself
i was just wondering if there is a easier method?
and whats that about security you are saying?:-)
#10
www.garagegames.com/blogs/32/10202
It worked perfectly for me right from the word go, passing dozens of variables to my php scripts.
11/27/2006 (5:25 am)
I have been using this http/php thing for a while following the model found in this plan by Mr. Labrat. He includes a URLEncode function which I think is what you're after.www.garagegames.com/blogs/32/10202
It worked perfectly for me right from the word go, passing dozens of variables to my php scripts.
#11
I'd also ensure that your backend PHP script is protected against SQL injection and XSS attacks; the other nice thing about hashing before you pass stuff to PHP via post or get is that it kills many attack vectors of this sort right out of the gate.
And aye, Labrat's URLEncode is verra nice. Plus, the entire way he sends his variables and junk in that blog is also very nice. It's just weird that the ampersand is getting converted on a stock script call using HTTPObject.
Oh and forgive my lack of coherence/stream of consciousness in this post; I've been up way too long...
11/28/2006 (12:09 pm)
Quote:and whats that about security you are saying?:-)Forgive me because I haven't tackled this much in TorqueScript, but in web app development where I have to shuttle secure info around I always do it via MD5 or better hash. So instead of comparing plaintext passwords, I compare hashes against hashes.
I'd also ensure that your backend PHP script is protected against SQL injection and XSS attacks; the other nice thing about hashing before you pass stuff to PHP via post or get is that it kills many attack vectors of this sort right out of the gate.
And aye, Labrat's URLEncode is verra nice. Plus, the entire way he sends his variables and junk in that blog is also very nice. It's just weird that the ampersand is getting converted on a stock script call using HTTPObject.
Oh and forgive my lack of coherence/stream of consciousness in this post; I've been up way too long...
#12
I'm doing that kind of job these days. I managed to get my goal by following two resources.
Those are persistent Character and MD5 .
I modified crc32 to md5 to get a better security. And I saved password using MD5() in my DB when my players want to register.
good luck to you.
Hongjin
11/30/2006 (6:05 am)
@Wolfgang,I'm doing that kind of job these days. I managed to get my goal by following two resources.
Those are persistent Character and MD5 .
I modified crc32 to md5 to get a better security. And I saved password using MD5() in my DB when my players want to register.
good luck to you.
Hongjin
#13
If you can avoid using them and use something like libcurl (exposed via C++ objects to TorqueScript, if necessary), you'll be happier in the long run.
12/15/2006 (10:48 am)
I realize it's tempting to want to just use whatever already exists in Torque, but TCPObject/HTTPObject have several serious shortcomings which are not easily remedied, and some nasty bugs (in 1.3, at least).If you can avoid using them and use something like libcurl (exposed via C++ objects to TorqueScript, if necessary), you'll be happier in the long run.
#14
12/15/2006 (11:52 am)
Please enlighten me on the bugs with TCPObject, Tim. "Nasty bugs" is not very specific.
#15
The TCPObject::table it uses isn't sufficient. Also, not exposing socket IDs through the API via processArgument parameters seems necessary (letting script create the tags that TCPObject uses internally to uniquely identify TCPObjects seems like a bad idea, particularly when the mechanism for getting events delivered to the TCPObject depends on the socket descriptor).
Because onDisconnect doesn't remove the object from the map, it relies on script (or other code) to delete the object and call the destructor to get it removed the map.
If, during the time between when a connection is closed remotely (onDisconnect), and the time the local side cleans it up, another connection is opened, and the underlying platform-specific socket code decides to reuse that particular socket descriptor, you have a problem. The implementation can't assume that onDisconnect means the object destructor is going to get called immediately, because script might be using that object still for something else (like, reading some TCPObject.foo property).
A new TCPObject is created, but contains a non-unique mTag... addToTable gets called with this tag/descriptor, which calls removeFromTable, but removeFromTable tries to delete based on the equality of the TCPObject instance (is it the same instance, vs. is the socket descriptor the same). So, it removes nothing, and now addToTable inserts a new TCPObject into the list at the array index matched by the tag.
Now you are in a situation where the network layer creates events which get dispatched to the wrong TCPObject (because processConnectedNotifyEvent uses find(), which only examines tags, because that's all it can really do).
This bug caused a lot of head-scratching for us because it was not easily reproduced.
HTTPObject was never really ready for prime time, I think (it may be now, but it wasn't in 1.3) -- it does only a fraction of HTTP.
It certainly seems to be a little bit of reinventing-the-wheel, in light of the fact that there are multiple, good, C and C++ libraries that contain a full and complete implementation of HTTP 1.0/1.1 that you can wrap with some additional code and reflect into script easily.
02/15/2007 (2:37 pm)
Well, one that was difficult to find has to do with the way TCPObject tracks connections.The TCPObject::table it uses isn't sufficient. Also, not exposing socket IDs through the API via processArgument parameters seems necessary (letting script create the tags that TCPObject uses internally to uniquely identify TCPObjects seems like a bad idea, particularly when the mechanism for getting events delivered to the TCPObject depends on the socket descriptor).
Because onDisconnect doesn't remove the object from the map, it relies on script (or other code) to delete the object and call the destructor to get it removed the map.
If, during the time between when a connection is closed remotely (onDisconnect), and the time the local side cleans it up, another connection is opened, and the underlying platform-specific socket code decides to reuse that particular socket descriptor, you have a problem. The implementation can't assume that onDisconnect means the object destructor is going to get called immediately, because script might be using that object still for something else (like, reading some TCPObject.foo property).
A new TCPObject is created, but contains a non-unique mTag... addToTable gets called with this tag/descriptor, which calls removeFromTable, but removeFromTable tries to delete based on the equality of the TCPObject instance (is it the same instance, vs. is the socket descriptor the same). So, it removes nothing, and now addToTable inserts a new TCPObject into the list at the array index matched by the tag.
Now you are in a situation where the network layer creates events which get dispatched to the wrong TCPObject (because processConnectedNotifyEvent uses find(), which only examines tags, because that's all it can really do).
This bug caused a lot of head-scratching for us because it was not easily reproduced.
HTTPObject was never really ready for prime time, I think (it may be now, but it wasn't in 1.3) -- it does only a fraction of HTTP.
It certainly seems to be a little bit of reinventing-the-wheel, in light of the fact that there are multiple, good, C and C++ libraries that contain a full and complete implementation of HTTP 1.0/1.1 that you can wrap with some additional code and reflect into script easily.
Torque Owner Greg Kefalas
Also, in your echo in onLine, if you want the contents of %line you need to remove the quotes from around it. I also noticed .cancel is misspelled .cancle.
This is just a cursory glance at your code, but start there... something else seems "off" but right now I'm too pumped full of beer after OSU game to really look closely ;)