Jump to content
  • Advertisement
Sign in to follow this  
rpiller

sign up on website login via game

This topic is 2608 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want my players to create an account on a website and then be able to log into my game client with that same account.

What is the most common way to handle this on the database side? I've noticed most places that host your website and give you a database don't allow external access to the database. So that would rule out my game client reading the website database of users.

Is it common to have the website call a webservice on the server that houses the database in order to modify data? Which that server could just be a server I rent and would have total control over. Is there some other way to do this?

Any recommendations on hosts for this kind of thing both website and database server?

Share this post


Link to post
Share on other sites
Advertisement

Is it common to have the website call a webservice on the server that houses the database in order to modify data?


A client should *never* connect directly to a database server. It should always go through an application server. A web server that can talk to the database server works well as an application server as long as you can live within the confines of HTTPS.

Generally, you'd want about three functions for the application server:

1) Translate username and password into a (time-limited) access token
2) Post some user-sourced data given the access token as credentials.
3) Invalidate an access token (== "log out")

Note that a hacker will be able to attach to your program while it's running, and edit the data in memory, before it's posted, so this does not protect against cheating users; only about people trying to cheat your users by stealing usernames/passwords. And you absolutely want to run all this over HTTPS if you at all are able to -- look for "firesheep" for why you don't want to use HTTP.

Share this post


Link to post
Share on other sites

A client should *never* connect directly to a database server. It should always go through an application server.
[/quote]

Yeah sorry that's what I meant. The client would be sending messages to my server application and it would be interacting with the database.


But I guess I'm still confused on how to go about this. I have a webpage hosted by a 3rd party. That 3rd party provides me with a database. The webpage has the login creation form that writes to that database. Now my server program (which isn't running on the web host PC) needs to read that database to validate when a user tries to logon via the client app. But most webhosts I've seen don't allow external programs (ie. the server app) to read their database that they gave you.

So what are my options in terms of architecture with this.




A web server that can talk to the database server works well as an application server as long as you can live within the confines of HTTPS.
[/quote]

So in practical terms, my webserver makes the call via a webservice to my DB server providing it the username and pw that a person just created an account with. Then my game client requests to my server app to login, and the server app connects to my DB server to validate the username/pw. Is that the idea?

Share this post


Link to post
Share on other sites

But I guess I'm still confused on how to go about this. I have a webpage hosted by a 3rd party. That 3rd party provides me with a database. The webpage has the login creation form that writes to that database. Now my server program (which isn't running on the web host PC) needs to read that database to validate when a user tries to logon via the client app. But most webhosts I've seen don't allow external programs (ie. the server app) to read their database that they gave you.


So, your main problem is that your hosting infrastructure is severely cost constrained, and you're prepared to live with sub-optimal application architecture to avoid spending money.

In this case, I would simply write some web APIs on that web server that allows CRUD operations, and secure them with a username/password for the "server," and treat the web server as the "back end" for your game server.

Share this post


Link to post
Share on other sites

So, your main problem is that your hosting infrastructure is severely cost constrained, and you're prepared to live with sub-optimal application architecture to avoid spending money.
[/quote]

I have nothing right now so I'm really just looking for the optimal infrastructure for this situation and if anyone has any pointers on a hosting house that supports the optimal solution. I was just throwing out a scenario.



and treat the web server as the "back end" for your game server.
[/quote]

From what I've seen a good number of web hosts won't allow external connection to the databases they give when you get your website.

Would you be able to layout the complete ideal infrastructure for this situation? The way I see it. You have a webserver for you website, and application server for your game server application, a DB server for your database. When a person signs up via the website their username and pw are sent to the DB server and stored. Then when they connect to your game all commands go to the application server, server app and that is what talks to the DB server to validate things. So if the DB server is on a different server than the web server how does that communication happen? Webservice?

Maybe I'm looking at horrible web hosts (everyone and their grandparents offer web hosting these days) so maybe there are some better web hosts that allow total control for something like this.

Note, I don't want to manage my own servers. I want them to be hosted by other people who know more about that stuff than I do. It would be great if there was one service that did all 3 (webserver, db server, & application server), but I've not seen anything like that. If you know of one I'd love to check them out.

Share this post


Link to post
Share on other sites

From what I've seen a good number of web hosts won't allow external connection to the databases they give when you get your website.


That's right! That's why I suggested that you create a web service that writes to your database, that your game server talks to. It will look something like:

Database <=> Webserver
Webserver "webpage" part <=> User's Web Browser
Webserver "webservice" part <=> Gameserver <=> Gameclient

Webserver has two "parts": a public "website" part that does registration and whatnot, and a private "webservice" part that your game talks to.
To make it so that a user can't cheat, by talking to your webservice and say "I'm the game server, and user hplus0603 got 1,000,000,000,000 platinum pieces!" you need a special name/password to secure the webservice part, that only the Gameserver knows.

Note that some vendors use "webservice" to mean something very specific (SOAP, or WebDAV, or XML-RPC, or whatever) -- I just use it to mean "any web requests your game server can make and the web server understands." You game server just does a POST to create a record, a GET to read a record, a PUT to update a record, and a DELETE to delete a record.

Would you be able to layout the complete ideal infrastructure for this situation? The way I see it. You have a webserver for you website, and application server for your game server application, a DB server for your database. When a person signs up via the website their username and pw are sent to the DB server and stored. Then when they connect to your game all commands go to the application server, server app and that is what talks to the DB server to validate things. So if the DB server is on a different server than the web server how does that communication happen? Webservice?[/quote]


In the ideal world, you use a multi-tier system that all lives in the same hosting infrastructure. Typically, you rent a few servers from Amazon ECC (or just rent one server and run all the services on it). Other providers include Linode, Rackspace, etc. If you have low-latency requirements such that virtualized hosts aren't good enough and you need real metal, you will lease the hardware from Dell or HP, and rent some space and IP capacity from a co-location facility. I'd expect the minimum cost where an Amazon-based set-up makes sense to be about $200/month; for a co-lo setup you don't want to go there under maybe $2,000/month. There are also places that let you rent physical machines, like 1-and-1 or serverbeach or interserver or whatever. Note that "web hosts" like HostGator or GoDaddy are not what you want for these kinds of set-ups, because they host web pages, not custom network services.

You would have different SERVICES, which may or may not be spread across machines. Those services would be:
STORAGE SERVICE -- typically, a database server; if you have lots of large, unique blobs (uploaded maps, or whatnot) then add a replicated file system of some sort. For example, MySQL, or PostgreSQL, or Redis, or Riak, or some combination.
APPLICATION SERVICE -- this is web-based protocols to do things like user management, high-scores, etc, and can typically be written as a REST-ful server. For example, J2EE on Java or WebMachine on Erlang.
GAME SERVER -- this is the custom server that runs your game. Typically written in C++ or similar using mostly custom code.
MESSAGING SERVICE -- this might be used for events that go between services or whatnot. For example, ZeroMQ or RabbitMQ.
USER INTERFACE -- this is the "web server" that provides the web-based portion of your system -- user registration, forums, etc. For example, PHP on Apache or Ruby on Rails.

The connections between the services may be arbitrary, but typically you'll want data requests to go through the application service to the storage service; push updates to go to the messaging service; etc.

Will your game ever grow to the size where this organization is strictly needed? Probably not. But you can still define these as separate processes on the same system, to keep it "neat and clean."
If you don't want to spend any money, then you can sort-of replicate the most important parts of this system through the proposal I made above -- write the webserver code in one language; make it be both "application server" and "web/user interface server" and have your "game server" talk to it using HTTP.

Share this post


Link to post
Share on other sites
Thank you so much for the explanation! This helps me see what is acceptable and what is ideal and gives me a good deal to think about in my architecture.

Thanks again!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!