DOMjudge / domjudge

DOMjudge programming contest jury system
https://www.domjudge.org
GNU General Public License v2.0
739 stars 259 forks source link

Allow user change password #2729

Open as6325400 opened 1 month ago

as6325400 commented 1 month ago

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.

vmcj commented 1 month ago

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.

nickygerritsen commented 1 month ago

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?

as6325400 commented 1 month ago

Alright, I don’t quite understand where the security issue might arise when allowing users to change their own passwords.

meisterT commented 1 month ago

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?

as6325400 commented 1 month ago

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)

meisterT commented 1 month ago

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.

as6325400 commented 1 month ago

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.

meisterT commented 1 month ago

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.

meisterT commented 1 week ago

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.

nickygerritsen commented 1 week ago

I think group makes the most sense? Since self register is also linked to groups.