Last modified: 2010-04-18 09:04:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13165 - Impossible to close an account properly on a private wiki
Impossible to close an account properly on a private wiki
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 23231
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-26 14:45 UTC by Guillaume Paumier
Modified: 2010-04-18 09:04 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Guillaume Paumier 2008-02-26 14:45:02 UTC
There is at the moment (to my knowledge) no proper mean to close an account on a private wiki where an account is needed to view the content. Such wikis are often private because they contain sensitive information that not everybody should be able to access. It often happens that such accounts are attached to users who have a temporary status in the organization. When this status expires, it is often desirable to remove the access of these people to the private wiki. An ugly way to do this is to delete users manually in the sql table. 

== Proposed solutions ==

An idea would be to create a new usergroup named "expired" that could be set and removed by bureaucrats through [[special:userrights]] for private wikis (which have $wgGroupPermissions['*']['read'] = false;). Users in this group should not have the "read" right ($wgGroupPermissions['expired']['read'] = false;). The "expired" usergroup should override the implicit read permission $wgGroupPermissions['user' ]['read'] = true;

Another solution would be to block the user, make his cookie expire and check if the user is blocked when he tries to log in.
Comment 1 Roan Kattouw 2008-02-26 15:47:39 UTC
You can do this by creating a group with read permission and denying read permission to anyone outside that group, e.g.:

$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['trusted']['read'] = true;

In MediaWiki, it's impossible to override a 'true'.
Comment 2 Guillaume Paumier 2008-02-26 15:55:02 UTC
Thank you for your quick answer. However, the workaround you propose is not workable on a large scale, since that would mean changing groups for all users except those who expire. I reopen the bug since the "invalid" applies to one of the solutions I proposed, it doesn't apply to the bug itself which still exists.
Comment 3 Raimond Spekking 2008-02-26 16:04:29 UTC
Please have a look at the PasswordReset extension ( http://www.mediawiki.org/wiki/Extension:Password_Reset ). A sysop can invalidate the passwords from users.

It seems it would solve your needs.
Comment 4 Guillaume Paumier 2008-02-26 16:19:35 UTC
Thank you. It is indeed a possible solution. Though, it seems this action "sets an invalid password hash". This definitive password scrambling offers no possibility to reopen the account later. The account closing should be reversible in case the user is later allowed to view the content again (the same way a blocked user can be unblocked and allowed again to edit the content).

If a separate usergroup isn't workable, maybe an option "Prevent user from logging in" could be added to [[Special:Blockip]]? And the logging in should be tweaked accordingly.
Comment 5 Raimond Spekking 2008-02-26 18:58:40 UTC
(In reply to comment #4)
> Thank you. It is indeed a possible solution. Though, it seems this action "sets
> an invalid password hash". This definitive password scrambling offers no
> possibility to reopen the account later. The account closing should be
> reversible in case the user is later allowed to view the content again (the
> same way a blocked user can be unblocked and allowed again to edit the
> content).
> 

After our IRC conversation today I installed this extension and tested it locally.

It is possible to

a) set a new password
b) disable the account by a special kind of password scrambling

In case of b) the user is unable to request a new temp password per email. But the sysop can reopen the account by setting a new password.
Comment 6 Guillaume Paumier 2008-02-26 19:46:23 UTC
Thank you very much! Marking the bug as fixed then.
Comment 7 p858snake 2010-04-18 09:04:42 UTC
(In reply to comment #2)
> Thank you for your quick answer. However, the workaround you propose is not
> workable on a large scale, since that would mean changing groups for all users
> except those who expire. I reopen the bug since the "invalid" applies to one of
> the solutions I proposed, it doesn't apply to the bug itself which still
> exists.

It would be a one off mass change though, then just who evers account created after that. You could even do a script that you feed its the name in a file and it does it via the api or the likes for the mass change.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links