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

JSON API: do not allow admins to manage site when the admin role has been edited #1427

Open
jeherve opened this Issue Dec 16, 2014 · 4 comments

Comments

Projects
None yet
6 participants
@jeherve
Member

jeherve commented Dec 16, 2014

Plugins like Multisite Plugin Manager allow super admins to change the admin role on network sites, thus blocking them from activating or deactivating plugins.

Jetpack's JSON API module goes around this limitation, since these admins will be able to manage the site from WordPress.com.

It'd be nice if we could detect when the admin role has been edited, and stop allowing remote management in such cases.

Suggested here:
https://wordpress.org/support/topic/plugin-management-option-on-multisite?replies=3

cc @mrjarbenne

@mrjarbenne

This comment has been minimized.

Show comment
Hide comment
@mrjarbenne

mrjarbenne Dec 16, 2014

It also looks as if the admin from a subdomain can potentially deactivate plugins that have been network activated (like BuddyPress). This may be an artifact of my being a super-admin, giving me permissions beyond what a subdomain admin can normally see. I'll need to do more testing, but in the subdomain menu on .com, I can see and deactivate Network Activated plugins. In the self-hosted dashboard, these would only be available from the Network Plugin menu: once they are activated, they disappear from the subdomain dashboard plugin menu.

There doesn't seem to be a mechanism in the .com Plugin Management panel to identify whether a plugin is network activated or activated site-by-site.

mrjarbenne commented Dec 16, 2014

It also looks as if the admin from a subdomain can potentially deactivate plugins that have been network activated (like BuddyPress). This may be an artifact of my being a super-admin, giving me permissions beyond what a subdomain admin can normally see. I'll need to do more testing, but in the subdomain menu on .com, I can see and deactivate Network Activated plugins. In the self-hosted dashboard, these would only be available from the Network Plugin menu: once they are activated, they disappear from the subdomain dashboard plugin menu.

There doesn't seem to be a mechanism in the .com Plugin Management panel to identify whether a plugin is network activated or activated site-by-site.

@jeherve

This comment has been minimized.

Show comment
Hide comment
@jeherve

jeherve Dec 16, 2014

Member

It also looks as if the admin from a subdomain can potentially deactivate plugins that have been network activated

The plugin appears, but the admins won't be able to deactivate network-activated plugins as they don't have the necessary permissions. I sure double checked, just to be sure, and clicking on the deactivation toggle doesn't do anything.

I agree we could do things better and come up with a nice error message explaining why you can't deactivate the plugin. Or better yet, hide the plugin if you can't activate or deactivate it because you're not a super admin. We'll work on that!

Member

jeherve commented Dec 16, 2014

It also looks as if the admin from a subdomain can potentially deactivate plugins that have been network activated

The plugin appears, but the admins won't be able to deactivate network-activated plugins as they don't have the necessary permissions. I sure double checked, just to be sure, and clicking on the deactivation toggle doesn't do anything.

I agree we could do things better and come up with a nice error message explaining why you can't deactivate the plugin. Or better yet, hide the plugin if you can't activate or deactivate it because you're not a super admin. We'll work on that!

@mrjarbenne

This comment has been minimized.

Show comment
Hide comment
@mrjarbenne

mrjarbenne Dec 16, 2014

Thanks for checking that out. I didn't have an alternate wp.com username not attached to a site as a superadmin. That's re-assuring.

mrjarbenne commented Dec 16, 2014

Thanks for checking that out. I didn't have an alternate wp.com username not attached to a site as a superadmin. That's re-assuring.

@jeherve jeherve modified the milestones: 3.4, 3.5 Jan 28, 2015

@dereksmart dereksmart modified the milestones: 3.6, 3.7 Jun 25, 2015

@samhotchkiss samhotchkiss modified the milestones: 3.7, Needs Triage Aug 28, 2015

@jeherve jeherve modified the milestones: 4.0, 3.9 Jan 15, 2016

@jeherve jeherve modified the milestones: 4.1, 4.3 Jun 17, 2016

@richardmuscat richardmuscat modified the milestones: 4.3, 4.4 Jul 7, 2016

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Jul 6, 2018

This issue has been marked as stale. This happened because:

  • It has been inactive in the past 6 months.
  • It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

stale bot commented Jul 6, 2018

This issue has been marked as stale. This happened because:

  • It has been inactive in the past 6 months.
  • It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

@stale stale bot added the [Status] Stale label Jul 6, 2018

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