create a RPC interface to retrieve account data

[dansan]

The replay site is dependent on a RPC service (like XMLRPC or webservices) for authentication. A half-written site for account management too. The Zero-K webservice info has begun to diverge from the official lobby server info.

The most important values used are

• accountid
• name
• aliases
• country
• rank
• email

The zero-k webservice worked like this:

dansan = client.service.GetAccountInfo("dansan", "SECRET")
>>> dansan
(AccountInfo){
   Aliases = "[f6]Dansan,Dansan,LovePeaceAndHarmony,dansan"
   Avatar = "seismic"
   ClanID = 0
   ClanName = None
   Country = "DE"
   EffectiveElo = 1091.98034668
   Elo = 1491.98035
   EloWeight = 1.0
   FactionID = 0
   FactionName = None
   IsLobbyAdmin = False
   IsZeroKAdmin = False
   LobbyID = 0
   LobbyTimeRank = 0
   Name = "dansan"
   SpringieLevel = 1
   ZeroKAccountID = 152636
   ZeroKLevel = 0
 }

There is ofc lots of zero-k specific - for spring in general unnecessary - information. LobbyID and LobbyTimeRank seem to not have survived the DB migration.

[dansan]

AccountIDs are back: https://github.com/ZeroK-RTS/Zero-K-Infrastructure/issues/383 , so users existing prior to zero-k migration are fine.

[abma]

accountid name aliases country rank email

1 why is email needed? 2 are these all values which are used? should be doable without a lot of changes 3 also i'm a bit confused about aliases. how is that "calculated", are aliases user renames?

i can only suggest to change TESTLOGINACCEPT to provide the values as named vars:

i.e.

TESTLOGINACCEPT id=1 username=blabla alias=alias1\talias2\talias3 country=us rank=5 email=user@server.com

https://github.com/spring/uberserver/blob/master/protocol/Protocol.py#L2820

i hope i didn't miss sth. but thats how it could work.

[dansan]

1 why is email needed?

Not for login, but for a web based password reset form.

3 also i'm a bit confused about aliases. how is that "calculated", are aliases user renames?

I think they are... at least for my accounts that is what the zero-k webservice returned as aliases. Aliases are just nice-to-have.

TESTLOGINACCEPT

I don't want to test those values, but retrieve them. A function signature like this: get_account_info(username, password) -> {''accountid": 12345, "name": "dansan", "aliases": ["santa", "clause", "maus"], "country": "DE", "rank": 5, "email": "dansan@springrts.com"} if auth=True else None

I'd prefer XMLRPC or webservices instead of the lobby protocol.

I'll try an implementation with https://docs.python.org/2/library/simplexmlrpcserver.html and propose a patch... Would you prefer this to run inside uberserver or as a dedicated service (standalone or as CGI with apache), reading from the same DB?

[abma]

hm, my proposal wasn't clear i guess. imo there are two solutions:

1. directly integrate the service to uberserver. makes it listen on an additional tcp socket which very likely is unencrypted. also some additional auth system is needed for that. every request will require an new authentification.
2. using a lobby client implementation which uses the build in encryption. the client runs directly on the machine which needs the service and listens on localhost for requests and forwards it to the lobby server. a request can be made through the existing connection no auth is required or only a very basic one as data doesn't flow through the net.

atm i prefer 2. because it is (it seems to be so) simpler. 1. would require to either directly allow tls connections to the service or use apache + tls as proxy to the service. 2. would allow both, the "client" thing can run on springrts.com server or at replays.springrts.com which imo is preferable. also 2. seems to have less overhead.

i hope now its clear what i meant? :)

[dansan]

Uh... I already wrote an implementation: https://github.com/dansan/uberserver/commit/47ba8b249f091cbc097309b9efccfa2adbbea399

It works, but atm. uses no encryption. I'd suggest to simply put it behind apache-ssl.

[abma]

what i dislike with this approach is that all security / limits are bypassed.

both solutions have drawbacks, i'm undediced :-|

@gajop

what do you think?

[dansan]

1. directly integrate the service to uberserver. makes it listen on an additional tcp socket which very likely is unencrypted. also some additional auth system is needed for that. every request will require an new authentification.

Stateless - good for web applications.

1. using a lobby client implementation which uses the build in encryption. the client runs directly on the machine which needs the service and listens on localhost for requests and forwards it to the lobby server. a request can be made through the existing connection no auth is required or only a very basic one as data doesn't flow through the net.

IMO this breaks security: If on a webserver (replays-site) a lobby-client runs that logs in using a single lobby account and forwards requests for account data, but does not authenticate each request - then it must have full trust.

atm i prefer 2. because it is (it seems to be so) simpler.

For whom? Not for the client. Implementing a lobby client is way more trouble than using a xmlrpc-client-library.

1. would require to either directly allow tls connections to the service or use apache + tls as proxy to the service.

I'll create a usable Apache-SSL-proxy configuration and post it.

the "client" thing can run on springrts.com server or at replays.springrts.com which imo is preferable.

I think so too. Having a public XMLRPC-API may inspire more services to be developed. What about allowing the wiki/forums users to authenticate with their lobby accounts (like zero-k.info and the replay-site)?

also 2. seems to have less overhead.

Only on the server side, and IMO the overhead is not that big that it'd be more important than being able to easily create more services.

At least for now there shouldn't be more than 1 request per minute (authentication on the replay-site by autohosts and web-users). The https://github.com/dansan/spring-accounts-site would produce even less logins than that.

[gajop]

Since I was asked, I'll share my opinion. I think security is not something that has to be a core concern for now as long as it can be added. Adding XMLRPC is OK, I think, but question is why not use JSONRPC/REST instead? REST is probably easiest to use on the client side (I've used all three and I'm really not sure what would be best). This is really a tough one. I think it would be best to just add whatever is best for dansan for now (due to a hasty server split), but leave it out of the lobby protocol. If we want to extend/work on this, we should have a much longer discussion about adding a new interface.

[abma]

I think security is not something that has to be a core concern for now as long as it can be added.

because of that it should be concered from the beginning when adding such things.

and yes, i agree, for the moment its best to add it now as we sadly are in a hurry :-|

[abma]

I'll create a usable Apache-SSL-proxy configuration and post it.

proxy config already exists for etherpad & buildbot on springrts.com. the ssl-cert is missing :)

[abma]

@dansan

pull request?

[dansan]

@gajop looks like https://github.com/joshmarshall/jsonrpclib provides an easy "upgrade path" to jsonrpc (w/o having tested it).

[abma]

@dansan:

the tls-is-missing problem still exists, how to solve? can you setup https for springrts.com? i'm only having issues getting a certificate, other stuff (apache config/proxy/...) is no problem :-|

[dansan]

I'll send you a mail you about this.

[dansan]

Code: #138 SSL: enabled 05.02.2015, xml-rpc behind apache-ssl

[dansan]

@abma as currently noone else is using this, you can restrict access to the xml-rpc URL to replays.springrts.com.