Jump to content

Dunedan

WFG Programming Team
  • Posts

    72
  • Joined

  • Last visited

  • Days Won

    1

Dunedan last won the day on August 2

Dunedan had the most liked content!

2 Followers

About Dunedan

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dunedan's Achievements

Sesquiplicarius

Sesquiplicarius (3/14)

72

Reputation

  1. @rossenburg Are the changes proposed by @smileysomething you can work with for the UI part?
  2. 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). 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. 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.
  3. 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.
  4. *bump* Any progress here or anybody else who want to take up this topic?
  5. While I'm not that familiar with the Pyrogenesis side of things, that sounds like it'd make a lot of sense. AFAIK changing the password is only possible after authenticating. 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.
  6. *bump* Anybody interested in contribution password change functionality? If there are any roadblocks regarding that just let me know.
  7. Please consider that @Stan` as the project lead might have a better picture of a situation than you do. 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.
  8. No idea if the lobby code in pyrogenesis supports something like popups. Afaik announcements are currently displayed as chat messages from "system".
  9. 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.
  10. These are just warnings. It should work nonetheless. There is already an open pull request, which will get rid of these warnings once merged: https://github.com/0ad/lobby-bots/pull/13
  11. That's the problem, it should be this instead: muc_admin: - allow: admin - allow: bots
  12. Of course it does and I didn't say otherwise. 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.
  13. My guess would be that you didn't open UDP Port 3478 in the security group of your EC2 instance. At least that port isn't reachable from the internet.
  14. 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. 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. 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. 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.
×
×
  • Create New...