domjudge
domjudge copied to clipboard
DOMjudge
Allow user change password
Description of the enhancement request
Introduce a feature that allows users to change their own passwords, with the option to enable or disable this functionality through settings. This will provide flexibility in cases where a fixed password is required, while allowing or prohibiting individual password changes when necessary.
The goal you want to achieve
The goal is to allow users to securely and conveniently manage their own passwords, while the jury can configure in the settings whether the default behavior is to allow all users to change their own passwords. It should also be possible to restrict certain users from changing their passwords individually.
Expected behaviour
Users should be able to change their passwords via their personal settings page. Administrators should be able to enable or disable password changes for users through system settings.
Any other information that you want to share?
DOMjudge is often used in courses on programming, data structures, and algorithms. In these contexts, student IDs or fixed passwords are typically used for long-term login throughout the semester. However, due to the recent feature in DOMjudge that allows downloading submission code, there have been incidents where some students log into others' accounts to secretly download the correct code. Given the large number of students in such classes, handling password changes individually becomes difficult. Therefore, allowing users to change their own passwords could help mitigate such issues while reducing the burden on administrators.
I think for such usecases you want to use the university authentication system and pass the user via the REMOTE_USER environment variable.
The reason I'm hesitant to have this implemented is that changing the password is now a admin only privilege, to make that someone can change their own user we open the risk that such an account can alter other users also which is worse IMO compared to using strong passwords.
You can easily disable the download of the submissions, that was added for exactly this risk so if this wasn't a problem before it can easily be disabled to prevent that this is an issue now.
I'm not sure if I'm that hesitant. Sure, it can be a security risk, but if we put it in a whole new controller action, I don't think there is more risk than having an error in the submission code where too can submit as another team?
Alright, I don’t quite understand where the security issue might arise when allowing users to change their own passwords.
Is the idea here to allow the user to reset a password (e.g. get a reset link via email) or have the ability to change the pre-configured password?
What I want to do is to have an interface for users to change their own password after logging in, without the need for any email functionality.
If we were to use email, it would likely require a significant change, right? (like setting up a mail server)
If we were to use email, it would likely require a significant change, right? (like setting up a mail server)
Yeah, that was one reason why I was asking.
I think adding simple password change functionality behind a configuration toggle (disabled by default) sounds good to me.
Yes, I think so too. If it seems feasible, I think I can give it a try.
Also, I would like to ask how often the version number of Domjudge is updated.
Also, I would like to ask how often the version number of Domjudge is updated.
We don't have a fixed schedule, but rather see whether we have accumulated enough changes to warrant a new version.
Thinking about this a little bit more, we might want to allow some users (say the jury) to change their password while not others (say teams during a 5 hour contest). So the configuration option could be more than just a simple boolean, e.g. a list of roles (or groups?) who can change their password.
I think group makes the most sense? Since self register is also linked to groups.