New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block user accounts #566

Open
CHTJonas opened this Issue Dec 22, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@CHTJonas
Copy link
Member

CHTJonas commented Dec 22, 2018

Pickup from the discussion in the Google Doc for #556 - allow specific user accounts to be 'blocked'.

  1. Email the user to inform them, potentially including a reason for the block.
  2. Force logout of any & all of the user's existing sessions.
  3. Prevent any new logins from that user's account.
@GKFX

This comment has been minimized.

Copy link
Contributor

GKFX commented Dec 22, 2018

I’d like to imagine this will never actually be necessary; in any case it could probably be achieved by suitably corrupting a row in acts_external_users.

@GKFX

This comment has been minimized.

Copy link
Contributor

GKFX commented Dec 22, 2018

Might also be good to have a way of blocking all users from editing, e.g. if we break the site in some way that means no editing at all is a useful safety measure, or during deployment of new releases.

In terms of implementation, having a BlockingVoter which essentially says no to any action if the user is blocked or if triggered manually would be easier to implement than logging out the user etc. Then you’d just need an entry in acts_access for each blocked user.

@CHTJonas

This comment has been minimized.

Copy link
Member

CHTJonas commented Dec 23, 2018

Might also be good to have a way of blocking all users from editing

Good thought. Could also revoke the INSERT, UPDATE, DELETE etc. privileges from the production user account on MariaDB. I also considered blocking individual IP address or CIDR blocks but I think Apache config might be the best place for that kind of thing if it ever becomes necessary. As you say this is more proactive than reactive and I doubt we'll ever actually need any of it.

Yeah I think a BlockingVoter sounds like the right way to go. That way would still let them read public stuff when blocked, and provides a form of blocking audit log too.

@philosophicles

This comment has been minimized.

Copy link
Contributor

philosophicles commented Dec 23, 2018

(Have commented to this effect in the Google Doc too)
Personally I don't feel it's massively worth doing any work in this regard until we have a genuine need for it. It's something I really hope we never actually need. But obviously, if someone wants to do development to add it in, sure :).

The temporary "block all users from editing" does sound like a slightly more useful feature, though. That'd be an adequate stop-gap if we had a seriously active abusive user - we could switch on the "global block" while figuring out exactly how to block that specific user.

@hoyes

This comment has been minimized.

Copy link
Member

hoyes commented Dec 24, 2018

Alternatively, https://symfony.com/doc/3.4/security/user_checkers.html would be a straightforward way of blocking a user from logging in at all.

We can probably tolerate making a manual DB change if/when we need to do this so can maybe get away without any admin UI.

The "global block" thing sounds useful. Could perhaps use an env var.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment