Hi,
I want to have a separate login system outside of Unity. However, once a player logs in, I want that data to be automatically entered into their game session so it recognizes who the player is from the initial login.
How can I do this? Is there a way I can “post” data into Unity3D text fields? Or maybe retrieve that data from a cookie?
Any help on this matter is appreciated.
I wouldn’t use the javascript method suggested above for anything to do with login information. Another way to pass data to the application is to just use regular WWW calls to a server-side PHP script… If you have a session started when you login on the html page, then the WWW calls should be part of that session too.
Thanks for the tip. I actually implemented the JavaScript → PHP method and thought better of it. I’m not a security expert but that didn’t seem safe at all.
I had the same thoughts when I was developing a Flash application which featured an HTML login. The issue was that you could publicly access the pages, but only if you logged in you could edit them (it is a Flash website builder tool)… Anyhow the issue was how to keep people from modifying the client-side code to mimic an authorized user.Theoretically it’s possible, but since the validation for anything happens on the server using session tokens (aka cookies) then it’s impossible for a user who hasn’t signed in to actually access to the database.
You can do validation immediately when the person opens the app (by checking some server-side script) or by passing a single-use token to the application as a publicly exposed parameter in the html/javascript. The token is single-use, meaning it’s generated and stored in the database when the user first logs-in, but is immediately trashed after being verified. All it does is tell the app “this user is logged in”. But to actually access/change sensitive data the server-side script is accessed and you need to be running the same session as the logged in user.
It’s like we’re thinking on the same wave pattern here! Last night I was thinking about the “single-use” token idea you described here, and it may be the only secure way to go about this.
I thought about various ways before bed:
JavaAcript/PHP send the data to the UnityApp. Cons: Could be mimicked outside of server and someone could use a key breaker to try and get a positive hit.
Download Page as Text file: Store the login page as a “text” variable sent to the Unity App as a string. Parse the page for information until you get the username/pass. This has the same weakness as above I feel.
Unique Key: Generate unique key associated with user name, pass key to UnityApp. UnityApp checks whose name the key is associated with. UnityApp logins that user, SQL deletes that key (this was the winner in my mind last night). I can’t find any weakness with this approach and it seems to be the most secure.
I’m glad I could bounce ideas off of you. This community is awesome.
Hey no problem. I think I got the idea from someone else in the Flash community a year or so ago. It’s good to spread the ideas around!
Just make sure that any time Unity updates the database or accesses sensitive information that the session of the request is verified.
As I said before, any http request made by the browser plugin actually goes through the browser, and thus if your Unity app uses a WWW object to get/set some data on the server, make sure that the private session token of that request matches the current session token which is stored in the database.
That means when someone logs in they get:
a) public single-use token, passed to Unity
b) private session-token, stored in database until user logs out or session expires.
The private token never needs to be exposed to the users machine at all. When they make a request to script.php then the script checks to make sure the session matches the session of the user associated with the request. (ie: if you are updating user “foo” then make sure the session token matches the stored token for “foo”)
Now that I think about I cant even remember the necessity of the public token… when you authenticate every database request… but I thought a lot about it on my previous project so I am pretty sure it was necessary or useful! 