requestmysql?
 

What's this for? :)

mayb it connects to an sql server for information? o_O

That would be what the name infers.

I tried using this a while back when was fiddling with requesturl and couldn't find any way to get it to work, or even what it returns if it works. Some insight would be nice, SQL access would be a lot easier than using requesturl all the time.

Both the server and client documents have it listed as:
requestmysql(str, str, str, str, str) - returns object

Yeah just saw that and deleted my post. :) Guess I was too slow. >_<

It'd be interesting to find out how exactly it is used.

It's not working yet, the idea was to allow communication to the database of playerworldname.graal.net

That explains why it hasnt been working for me..

I thought it was
requestmysql(server,account,password,database,quer y);

which would make sense.. and if thats not how its going to work you should add a command like that so it can communicate with any mysql server.

hmmm i think we could write our own requestmysql() function that uses requesturl() and a php file or? :o

Well, you could, but I doubt it would be very secure, practical or easy to implement.

this would be SUCH a sweeettttt swweeettttt way to use that =p, oh the possibilitys

hmmmn

can use it and have and do something like..

domain.com/sqlquery.php?acc=SQLACC&pass=SQLPASS&db=DBNAME&que ry=QUERY

would be as secure as any other command to access mysql through graal.

would still need to know accname and password

yeah and you could make a class for that function
and give noone read access to the class haha xP

It's this whole thing about sending your SQL details through a URL that probably concerns me. I realise that the chance of someone picking up on them is slim, but still, web server logs and such.

MySQL commands would be much more secure, if done on the server end.

well you could use encryption haha

How secure is comparing an MD5 result, as the password?

well i dont know if u can use md5 because its one of this one-way encryptions, but i think at a php file you have to write the unencrypted password in...
or you could just connect at the php file and make a database for passwords

MD5 is NOT a form of encryption.
http://en.wikipedia.org/wiki/Md5

I already know that. I asked if MD5 comparison was a simple but relatively safe method?

Any plans to enable this function anytime soon?

>.>
 

First off, you DON'T need to send the password OR username, you make a config PHP file for that; Sending ANYTHING as get vars (The vars after ?, seperated by &s), is INSECURE, and downright retarded. Second, MD5 is hashing, it is one way, and it's common sense how you use it, no word will hash the same way, so you just hash both and compare. If you don't know about SQL Servers, don't even try them, just use scripted databasing. If you got your own SQL server, create an account that can only send INSERT and SELECT, that's all you need to add and read from a database.

Eh, it is not really any more or less secure than opening a socket to your sql server and shooting data down it.

><
 

It's very insecure, get data can be read by anyone, thus anyone seeing the username and password can use a database manager to hack in, whereas using a PHP file, your using serverside vars, noone can see them, And the only accesses that can be made are serverside.

That was not really my argument; my argument was about sending GET variables as a part of a HTTP request.

;o
 

GET vars are always insecure, no matter the case.

Yeah, while you could use php as a way to access mysql it's not secure using GET vars and sending whole queries is very insecure since anyone who had access to the script could manipulate the database. Of course sending the password as a GET variable could make it slightly more secure if someone just had the script, but if you were connecting from graal clientside someone could just use a packet sniffer and get the info.

If you're going to access mysql through graal via php you should check the IP address of the person who called the script. This way you can limit it to the graal server getting access to your database. Of course this would make it impossible to connect to your database from a clientside script.

That would be a terribly inefficient way of connecting to mysql since it would make a new connection to mysql every time it performed a query.

Keep in mind too, that querying mysql on another machine is, in most cases, going to be slower than creating a database npc to do the job.

Good point.
 

It isn't ENTIRE insufficient, but it would be like making a bunch of pages that are used to grab one var each, then loading all those pages at once..... It'll work normally, causing lag on slower servers :)

Oh! Also,
 

As I just posted in the main board, seems requesthttp's 3rd argument can be of some use to checking if Graal is the requestee. That would mean you can only do the coding IF the client is accessing through graal. I'll be working on getting my account info in a database, on www.bladestrife.net/nsc/user.php

Actually I found a way to help detect whether it's graal or not.

Graal does not set most of the HTTP variables. HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT_CHARSET, HTTP_KEEP_ALIVE, HTTP_CONNECTION are all not set by graal, you could check to make sure these are all not set in your php script.

That should be enough to stop most wannabe hackers. Of course it would be possible to mimick this behaiviour using cURL or through another scripting like php or perl (WWW:mechanize could do this with ease, unfortunatly).

If functionaility was brought in so we could set one or more of these variables ourselves we could make it a lot more secure because we could use these values as checks. You could set them as something in graal and check them in your php script. (of course doing this from clientside would still leave it open to packet sniffing, but no moreso than a requestmysql() function.)