Jump to content


WFG Programming Team
  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Dunedan

  1. 21 hours ago, rossenburg said:

    Users who do not remember their passwords and are stuck in the log in page 

    The feature to be able to change the password, won't help such users at all, as they can't proof that the account they want to change the password for is their own account.

    There is a difference though between users who don't remember their password and don't have it stored in 0ad (these are the ones which can't change their password) and users who don't remember their password, but have it stored in 0ad (those ones can still log in and should also be able to change it).

    21 hours ago, rossenburg said:

    I believe there's a need to somehow verify that someone who has case 1 , really owns the account they wish to update the password of. Else i can just go ahead and reset someone else's password or something

    How would you do that? As you don't have their password you can't be logged in into their account, which is a prerequisite to changing the password.

    21 hours ago, rossenburg said:

    I dunno if im thinking way too broad, can you suggest how the whole process should be? , if possible in some kind of pseudocode or step by step listing 

    Essentially it's the same as for most websites which offer accounts: To change your password, you have to log in first. Once logged in there is somewhere a form you can use to change the password. Note that this is different from a password reset process which usually doesn't require a login, but something like a recovery email instead. That's a use case we can't cover for now.

      • Like 1
    1. On 19/10/2022 at 7:26 PM, rossenburg said:

      For extra security, users are asked to confirm their old password before updating the old password ( just so, if someone else has an account that doesn't belong to them they won't be able to change password ). I dunno if its best to compare the encrypted form of the old password in other to achieve this since its stored locally or there's more efficient way.

      AFAIK neither gloox nor ejabberd support checking the current password during password changes, because you can change your password anyway only when already being authenticated. So to implement that you either have to check against a locally stored password or do some re-authentication during the password change.

      Checking against a local stored password is something which can be circumvented with a patched version of 0ad and isn't straight forward anyway, because storing the XMPP password is optional. Doing re-authentication with the XMPP-server during password change adds a lot of additional complexity and isn't as it's usually done with XMPP.

      Also keep in mind that most players which have stored their password in 0ad probably don't even know anymore what their password is and therefore wouldn't be able to change their password at all, if a password change would require typing in the current password.

      What would be the benefit of checking the current password anyway? In which situations would that provide a benefit? The only situation I can imagine right now is when granting an untrusted person access to your computer, but that's a case we shouldn't try to handle. If an untrusted person has access to your computer they can also simply install a keylogger and get the password that way.

      My suggestion is to keep the initial implementation as simple and straight-forward as possible. Avoid stuff which adds complexity in terms of code as well as in terms of user experience if it doesn't provide a significant benefit.


      • Thanks 1
    2. 10 hours ago, smiley said:

      I think what we need to do is make XmppClient an actual singleton which isn't constructed based on the behavior we need. And than we can instead call xmppRegister, xmppLogin, xmppChangePassword etc rather than constructing three slight variations of it for each mode.

      While I'm not that familiar with the Pyrogenesis side of things, that sounds like it'd make a lot of sense.

      6 hours ago, smiley said:
      // Allow unauthenticated
          virtual bool Login(const std::string& username, const std::string& password) = 0;
          virtual bool ChangePassword(const std::string& newPassword) = 0;

      AFAIK changing the password is only possible after authenticating.

      6 hours ago, smiley said:
          // Pyrogenesis functions
          virtual const std::list<XMPPUser>& GetLeaderboard() const = 0;
          virtual bool RegisterGame(const XMPPGame&) = 0;
          virtual bool UnRegisterGame(const XMPPGame&) = 0;
          virtual bool ReportGame(const XMPPGame&) = 0;
          virtual const XMPPGame& GetGame(const std::string& hostUsername) const = 0;
          virtual const std::list<XMPPGame>& GetGames() const = 0;

      I guess you're aware, but there are several Pyrogenesis related functions (like "ChangeGame" and "GetProfile") missing.

      As a disclaimer: I'm currently working on the server-side for PubSub (https://trac.wildfiregames.com/ticket/4203), which will require some additional changes for Pyrogenesis (like subscribing for the relevant PubSub nodes), however I believe that should happen separately and after such a refactoring.

    3. 11 hours ago, Norse_Harold said:

      That makes it sound like user1 is completely to blame for the lack of software upgrades to the lobby. Let's please avoid placing blame because I'm sure that not only one person is to blame for the impasse.

      Please consider that @Stan` as the project lead might have a better picture of a situation than you do.

      11 hours ago, Norse_Harold said:

      Another idea: offer to help Dunedan with the CI and pipelines on Github for the lobby server software in a way that does not require giving you administrative privileges. Ask what exactly they're stuck on, provide instructions and pointers to articles that answer questions, provide advice on best practices and anecdotes about how similar problems were solved elsewhere.

      The code for the bots is open on https://github.com/0ad/lobby-bots and contributions are always welcome. In case you're willing to contribute, but don't know what to tackle, feel free to reach out to me.

      Aside from the bots, contributions for the 0ad client side lobby code would be much appreciated, as I only work on the lobby bots and server-side lobby setup. A month ago I called for an implementation of password changing functionality in 0ad, but so far nobody has come up with an implementation.

      Please also be aware that I'm by no means blocked by technical topics, but rather how certain things are getting handled at WFG, but that's nothing to discuss here.

      • Like 1
      • Thanks 1
    4. 6 hours ago, Stan&#x60; said:

      @Dunedan What do we need for 2v2 and 4v4 rankings?

      First of all there needs to be a consensus how this should work. Should there be one rating or one for 1vs1 and one for multiplayer games? Also I'm not sure how good results for rating multiplayer games would be with the current ELO implementation. Maybe it'd make sense to switch to another rating algorithm for that.

      Once all these details are clarified it's just a matter of enabling/implementing the necessary support in EcheLOn and enable sending of game reports for multiplayer games with more than 2 players in pyrogenesis.

    5. 37 minutes ago, potoelite said:

      I found that rating bot uses sql database, unlike you said before.

      Of course it does and I didn't say otherwise.

      39 minutes ago, potoelite said:

      Could you please explain how to fix this?

      You likely didn't properly configure ejabberd, so EcheLOn doesn't get the JID of users joining the MUC room. To fix that you have to either ensure that the MUC room isn't anonymous or that the bots have MUC admin permissions. How to configure any of that is documented in the README.

      If you can't get that to work, posting your ejabberd.yml here would be helpful for further debugging.


    6. 23 minutes ago, potoelite said:

      So this means that hosting/joining game is impossible even after all is configured well?

      Sorry for being not clear. That means you should be able to join the lobby and chat there without the bots. With the bots correctly configured hosting games and having ratings available will work.


      26 minutes ago, potoelite said:

      But as the game uses encrypted password by itself, so I can't use the account create by game in other xmpp client as password is regarded incorrect.

      When registering an account with 0ad not the provided password will be used as actual password of the account, but a hash of it. You can find this hash in the 0ad config file and can use it as password to connect with other XMPP-clients.

      21 minutes ago, potoelite said:

      Also I'm wondering about who sends this message to the game client.

      As @Stan` already mentioned: That message is the topic set for the #arena26 MUC room on the Wildfiregames lobby server, so technically ejabberd is sending it to you.

      24 minutes ago, potoelite said:

      I have configured ejabberd on aws ec2 instance.

      Right now this ejabberd instance is publicly available and everybody can create accounts there and connect to it. I'm not sure if that's intended. I just created an account there and can confirm: registering via 0ad works, login via 0ad doesn't. However login with other XMPP-clients works, which is something I haven't seen before.

      I did some debugging and figured out what the problem is: When you try to log in using 0ad, 0ad connects indeed successfully to the server, but when it then tries to join the "arena" MUC room it receives an unexpected response, as that room doesn't exist and the user is also not permitted to create it. So creating the "arena" MUC room should get 0ad to work.

      In case you were also getting "authentication failed" messages in 0ad, that's because 0ad does only seem to the password, when the connection to the lobby was made successfully, which isn't the case right now. Typing in the password again before connecting solves this.

      • Like 1
      • Haha 1
    7. 2 hours ago, potoelite said:

      At this point, I have following problems.

      - I can register new account to multiplayer lobby, so I can confirm this in ejabberd admin page also. But I can't login with created account in the game.

      Login dialog keeps saying "connecting..." after the connection is established. Why I think like this is because the account which I used is displayed as online status in ejabberd web admin, but not in the game. In ejabberd log, it also says new connection is opened.

      - Server returns nothing response.

      At that point the bots play no role yet, so you can ignore everything related to the bots. Your problem must be related to the ejabberd setup or 0ad configuration. Even without the bots you should be able to enter the multiplayer lobby. What won't work without the bots is hosting games and rating of games, but connecting to the lobby and chatting there doesn't need the bots.

      To help you further we'd need some more information, like the 0ad configuration options you used, screenshots of the problem and a debug log from ejabberd.

      2 hours ago, potoelite said:

      I guess there is one more component to be installed for proper work of multiplayer lobby on my side.

      No, everything you need should be in the README (albeit some details might be outdated).

      2 hours ago, potoelite said:

      There isn't any postgresql db handler on my model and both source code of game and multiplayer lobby-bots don't contain any one of above strings.

      You don't need PostgreSQL. ejabberd should be configured to use its included mnesia database and EcheLOn can use any SQL-database supported by SQLalchemy. It defaults to sqlite if you don't explicitly configure something else.

      2 hours ago, potoelite said:

      Also, the weird thing is that github repo name is just "lobby-bots", not "lobby", which means entire name of system

      There is no separate repository for the "lobby" itself, as the lobby is just ejabberd with the configuration mentioned in the README.

    8. 27 minutes ago, Darkcity said:

      Thanks for claifying. When this feature being deployed, warn players about not sharing their account details with other players becasuse after this feature, they can change the password and will never share credential with original player :p. 

      I believe that won't be necessary, as sharing accounts isn't permitted anyway and loosing access to a shared account does already happen right now when the account gets banned for any reason.

      • Like 1
    9. 2 hours ago, rossenburg said:

      And aside that, allowing users to change account passwords without any further verification (either there's active session or not) will just promote more stress on the server since i can change my password 10times in 2mins, unless maybe we think of adding something like throttle middleware or password reset cooldown to the whole process

      Changing your password 10 times in 2 minutes does not stress the server running the lobby at all. Much more often might, but we have rating limiting against such DoS attacks in place, therefore considering any additional rate-limiting isn't necessary.

    10. Sorry for being not clear about that, but as @smileyalready clarified I was talking about changing the password after successful authentication. So this thread is not about a "forgot password" feature or how to also collect a users email address during registration, as that would be much more effort, but solely for allowing an authenticated user to change his password. That should be, as mentioned in my initial post, pretty straight forward. Please stay on that topic here and discuss additional ideas in other threads.

    11. Up to now 0ad doesn't offer the ability for users to change their passwords for the multiplayer lobby. However, that'd be a great feature to have and has in fact been already a feature request for several years (https://trac.wildfiregames.com/ticket/2543).

      I had a quick look and believe this should be pretty straight forward to implement, as the server-side as well as the XMPP library used by 0ad already support that. So all left to implement it is to add some glue code to 0ad and build the UI for it.

      If you're interested in helping out and implementing this feature or have any questions, please reply to this post or send me a PM.

      • Like 4
      • Thanks 1
    12. 38 minutes ago, smiley said:

      An alternative but slightly unattractive solution in terms of maintenance and dependency on ejabberd is writing up a module to handle some type of age query IQ.

      Yes, that would work as well, but I'd like to avoid that for the reasons you mentioned.

    13. 19 hours ago, Sevda said:

      There is one thing which I didn't understand: how can a smurf detection algorithm work on the server side? Smurfs are discovered by players who see a new account playing like experts and talking with 0AD jargons. I'm not sure how the server can tell these details.

      If you as a player see somebody you consider a smurf, why do you need any codified algorithm at all? Wouldn't just not playing with this player be sufficient? I believe this thread is more about automated detection, which helps detecting non-obvious smurfs.

      19 hours ago, Sevda said:

      Furthermore, even if you do install such an algorithm, I would recommend only allowing it to flare up smurf suspects to the moderators instead of pre-emptively taking actions themselves. AIs are quite likely wrong and the lobby would be a mess if it bans a moderator or WFGbot.

      I'd suggest not taking any preemptive action on server-side anyway, but instead leaving it up to players if they want to get likely smurfs tagged in the UI or even excluded from their games. That'd then have to implemented client-side.

      • Thanks 1
    14. To clarify some assumptions about what information we store server-side and can make available to 0ad clients:

      0ad only sends game reports for rated 1vs1 games to the lobby bots (see https://github.com/0ad/0ad/blob/3faa301ee914b82b1bfd89f2e89bc6392e244997/binaries/data/mods/public/gui/session/lobby/LobbyRatingReporter.js#L55-L56). Therefore we have no record of unrated or multiplayer games with more than two players in our database. That's because the bots were built for two purposes: enabling multiplayer functionality and keeping track of ratings. For both of that keeping track of unrated or non 1vs1 games wasn't necessary. Detecting smurfs wasn't a requirement back then. I'd be open to store reports of unrated and non 1vs1 multiplayer games as well, to be able to provide more information like aggregated values of play rated and unrated games to 0ad clients, if the consensus is that this would be useful. Doing so would not only require changes to 0ad, but to the lobby bots as well.

      Regarding the account creation date: We do store the date when players create an account, but that's not accessible to the lobby bots right now. Here is the database structure EcheLon, the bot responsible for handling rating related stuff, uses: https://github.com/0ad/lobby-bots/blob/8549e62dd40fd582412b4c8fc829fc672e8ddd17/xpartamupp/lobby_ranking.py. From that you can see that players have no date associated with them. You might also notice that we don't store the date for when a game happened. My proposal here is to change that so that EcheLOn stores the date whenever he gets the first request for returning player information (which happens immediately after player registration) and to store the date a game finished, based on the time its reports get submitted to EcheLOn, as well. I believe storing the dates is a no-brainer and something we should do in any case. After implementing that, we could return the registration for all players created after the change to 0ad clients. Independently from smurf detection that's probably something which would be interesting to display in the player profile.

      Last but not least there is some point I'm wondering about, which hasn't been addressed yet (unless I've missed it). In this thread there seems to be the assumption that the logic for smurf detection will be integrated into the 0ad client. I wonder if it wouldn't make more sense to do that server side, as that'd allow adjustments of the "smurf detection algorithm" between 0ad releases and would allow incorporation information into the algorithm which might not be suitable to return to 0ad clients (e.g. for privacy reasons). When doing the detection server-side only some kind of "smurf likelihood score" would need to be made available for 0ad clients. What are your thoughts on that?

      • Like 3
      • Thanks 2
    15. 4 hours ago, Stan&#x60; said:

      Fix here waiting for review by @user1


      Actually reviews by everybody who feels confident assessing the changes of such PRs are appreciated.

      I'll also soon merge this and some of the other PRs, no matter if somebody looked at them or not, as otherwise the development of the bots is blocked too much by waiting.

      Please mind that merging this PR won't result in the bug being fixed in the actually lobby immediately, as the bots running there have to be updated to use the new code and that might still take a while until we have a better process for that.

    • Create New...