Page 1 of 1

Email verification - protocol info

Posted: 21 Sep 2018, 19:33
by Silentwings
Uberserver now supports email verification, for registration and for changing email address.

This means some unavoidably breaking changes in the lobby protocol will happen, and lobby clients will need to be updated. It isn't live yet, there will be time to update - this post provides the info of what's coming.

To verify an email address: the server sends a four or eight digit verification code to an email address, and the client must send this code back to the server. Each verification code is valid for 48h, and allows max 3 attempts at verification.

Related breaking changes / new commands:
  • REGISTER needs a valid email address. When REGISTRATIONACCEPTED is sent to the client, a verification code will be sent to that email address. This code must be returned inCONFIRMAGREEMENT, or the server will reply with DENIED.
  • To change email adress, CHANGEEMAILREQUEST should be sent first. When CHANGEEMAILREQUESTACCEPTED is sent to the client, a verification code will be sent to the new email address. This code must be returned in CHANGEEMAIL, to change the registered address.
  • To reset a password, similarly, RESETPASSWORDREQUEST and RESETPASSWORD are used. In this case the user doesn't need to be logged in first. Once the code is returned the user is sent another email informing them of their new, randomly generated, password.
  • Verification codes can be resent, up to 3 times, using RESENDVERIFICATION.
See inside the links for complete details of new parts to the protocol, and for a general outline see inside the 'sub-systems' section of the lobby protocol intro.

After the changes go live, lobby clients that do not update will still be able to log users in (as before) but will become unable to create new user accounts or change email addresses. Instead, they will be sent an error message asking the user to update.

Each new account requires a unique email address. The long term plan is that email addresses will become part of linking lobby/forum/etc accounts. (More work is needed before that can happen, on linking the forum/lobby dbs, etc.)

Re: Email verification - protocol info

Posted: 21 Sep 2018, 22:05
by hokomoko
Absolutely marvelous!
Many thanks!

Re: Email verification - protocol info

Posted: 22 Sep 2018, 11:58
by ThinkSome
Silentwings wrote: 21 Sep 2018, 19:33 Instead, they will be sent an error message asking the user to update.
Can this error message and the email that is sent also include a link to a website where people can read the agreement and complete registration? There is no need to burn off old lobbies like that.

Re: Email verification - protocol info

Posted: 22 Sep 2018, 12:16
by Silentwings
Can this error message and the email that is sent also include a link to a website where people can read the agreement and complete registration?
See the last time you asked this question - https://github.com/spring/uberserver/is ... -417661625.
ToS sent via email is not going to happen, we have to make a visible effort to see that the user reads them.
There is no need to burn off old lobbies like that.
Also, it wouldn't help unmaintained lobbies; they have no facility to send an email address with REGISTER.

Re: Email verification - protocol info

Posted: 25 Jan 2019, 23:57
by ThinkSome
Add a http listener to uberserver and forward a directory on springrts.com to it?

Re: Email verification - protocol info

Posted: 26 Jan 2019, 09:27
by PicassoCT
I cant wait to get banned

Re: Email verification - protocol info

Posted: 30 Jan 2019, 21:26
by PicassoCT
They might be GPL Compliant...

Re: Email verification - protocol info

Posted: 31 Jan 2019, 08:32
by PicassoCT
We reject the German Democratic Postapocalyptic Republic

Re: Email verification - protocol info

Posted: 02 Feb 2019, 10:23
by Silentwings
The short answer is the document exists, but wikifying it is only coming as part of the current rounds of lobbyserver updates. Although we have always had a brief non-technical description of the servers data handing availabe in the terms, and in theory the details are checkable because the software is open source, we would like to give a much better non-technical set of info - this was in the works for a while.

It does get balanced aginst the importance of other things, as well as the practical side of fitting a change to the info provided to users on registration / acceptance of terms into lobbyserver development. Only one minor change to actual code is planned, we'll probably opt for automated deletion of replays after X years (currently it happens manually after around 3-5 years).

I think you might have asked your question in a nicer way, for example "does the document exist?".