Quote:
Originally Posted by trevius
The whole concept of this idea would be to have dual LS capability for server. People would set their server to connect to the public LS just like normal (though, that would be optional and not required if you just wanted to use the Private one). Then, they would also set it to use the Private LS running on their own server and using their own accounts database at the same time. Ideally, servers would be connected to both all of the time. But, in the case that the Public LS goes down for any reason, their players could then change their eqhost.txt to point to the private one for that particular server. Also, if people wanted to avoid the Public LS even when it was up, they would still be able to use just the Private LS for that particular server since they would both be connected at all times.
The private LS wouldn't use the LS account ID numbers like the Public one does. Authentication for the private LS would ignore the "lsaccount_id" field completely since it would have no way of knowing what it should be. Instead, it would use the password field when people log into their private LS and then just forward any accounts that pass the authentication check at that point straight to the server as authenticated. That is it.
|
I second.
I think it would be good to have an option to turn off the "public" part of it for those who either just want to play on a LAN, or just don't want to be connected to the public login server (either in the short term during development, or in the long term for whatever reasons).
I think ideally it would be best to incorporate this into world, but we'd need to keep the crypto out of the source (.dll, .so, etc) so others can't just start packet sniffing client authentication & reverse the username/password hash.
Quote:
Originally Posted by image
I see what we are getting at with the shared LS, we would need a way to generate UNIQUE id's that way, sort of like how everquest has those item id tags.
The reason I say this is, if I have LSID account 1 on my public server (which we obviously do), the private server would have LSID 1 of a different user. The Login server uses the LSID to identify and pass. Yes you can setup a private password with #setpass if they have the tables meshed in the same database, but the LSID would still be an issue.
So I think this would require a bit of re-work.
Edit: The reason I want unique LSID's is there still are a lot of database functions/calls that use the LSID and this would cause problems with login and world.
|
I think if we change to use the id rather than the lsaccount_id from the account table, that should help clear that up. Then, if an account authenticates via the public login server instead, we can update the lsaccount_id column with the info, but still use the local id.
After brief digging into the world source, I wasn't able to determine how dependent we are on the lsaccount_id, so I'm not really sure how difficult of a change this would be.