If the same IP address tries to register more than 1 account per registration_timeout, the ejabberd server will send a resource-constraint error.
D87 used a workaround to display a 0ad specific notification is players are not allowed to register multiple accounts within a time specified by the ejabberd config.
The workaround was used because gloox had no implementation to catch the specific error message thrown in that case (defined by XEP-0086 and XEP-0077.
As of gloox 1.0.19, gloox https://bugs.camaya.net/ticket/?id=267 | supports]] this.
D483 will update the bundled gloox version. linux versions will most likely be shipped with the most recent version of gloox.
Updating the OSX version would be nice, but since those users are rare in comparison to windows users, it is unlikely that moderators will be spammed with questions about this limit.
Details
On unix, check for your local gloox version with gloox-config --version.
Replace 0x010019 with your version and change RegistrationConstraint to RegistrationConstraintDOESNTEXIST to verify that the version check works.
Search the ejabberd manual for resource-constraint errors and notice that the IP address case should be by far the most likely chance to get this error message.
Notice from D319, that the client receives a different error (RegistrationForbidden) when registering an account if IP ranges are blocked or when registrations are disbled altogether.
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Branch
- /ps/trunk
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 1779 Build 2819: Vulcan Build Jenkins Build 2818: arc lint + arc unit
Event Timeline
Build is green
Updating workspaces. Build (release)... Build (debug)... Running release tests... Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK! Running debug tests... Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
http://jw:8080/job/phabricator/1238/ for more details.
| source/lobby/XmppClient.cpp | ||
|---|---|---|
| 1084 | Shouldn't this be CASE(RegistrationConstraint, g_L10n.Translate("Reg....? And why this "or two" at the end? | |
Shouldn't this be CASE(RegistrationConstraint, g_L10n.Translate("Reg....?
Oh, indeed. RegistrationForbidden must be changed too then, because it'shown to users when disabling registations for an IP range or everyone.
why this "or two" at the end?
Well, the time can be configured, so it would be great to keep this somewhat generic.
Users are not allowed to register accounts so quickly is what ejabberd sends. But that still leaves the question unanswered how long players will have to wait.
A more elaborate patch would rewrite gloox error handling to also catch that string.
Additionally I don't think we'll need the version check here.
We shouldn't break the compilation on systems that don't have a gloox version from 2017.
Either use it to return "" for Unknown Errors with older versions or just remove it.
So you mean the correct patch would be no patch? Disagree, we can catch this error slightly better than before. The ejabberd manual leaves the impression to me that the ResourceConstraint error is only realistically sent in this one case.
Actually translate that and the "Registation forbidden" one from D319 too.
Use the same phrasing as ejabberd.
Notice the case order is consistent with the one from gloox.
How does this patch break compilation with older gloox versions?
Either use it to return "" for Unknown Errors with older versions or just remove it.
So you mean the correct patch would be no patch? Disagree, we can catch this error slightly better than before. The ejabberd manual leaves the impression to me that the ResourceConstraint error is only realistically sent in this one case.
No
| source/lobby/XmppClient.cpp | ||
|---|---|---|
| 1084 | What about adding its normally one hour? | |
Build is green
Updating workspaces. Build (release)... Build (debug)... Running release tests... Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK! Running debug tests... Running cxxtest tests (306 tests)..................................................................................................................................................................................................................................................................................................................OK!
http://jw:8080/job/phabricator/1241/ for more details.
"Registration constraint error. Wait." is exactly the information we receive from RegistrationConstraint.
Whether this usually occurs because the same IP address is not allowed to register accounts so quickly is configurable serverside and removing this defeats the purpose of the various claimed fixes.
The current string containing serverside config options is located in JS, where it is possible to change it if the server config changes, without changing engine code.
Changing the error message handler of gloox to support parsing and returning the reason string would present that information to the client without including server config option (ideally without implement the deprecated XEP-0086).
Nor going to break compilation on platforms that don't have gloox 1.0.019 or later without a reason.
What about just sending the english string of the errortype to js and map them in js to a translated error message?