Disable ActivityPub publishing for the admin account.

[ichderfisch]

As previously asked on Mastodon, I'd like to have an option deactivate this feature for the Admin-User Account.

I consider this a security issue, as random brute force attacks on Wordpress sites typically start by guessing the admin account. Therefore I don't want to expose my admin account (which equals the ActivityPub handle) and wish is to have a option that let me deactivate that feature for this specific user. Maybe at the bottom of the user profile, where all the users ActivityPub information are visible (a toggle would be enough). Additionally a note at the Health/Status-Page would be nice.

In the latest update you've enabled the feature only for users with publish_posts permission, but this doesn't help me at this point, because I can't (or don't know revoke) this specific permission for the admin user.

[mediaformat]

Admin account is typically easy to find, /wp-json/wp/v2/users/1 will show the username. So security through obscurity falls a bit short.

You might consider creating a new user just for publishing.

[pfefferle]

@ichderfisch I agree with what @mediaformat said and wanted to add a second point: the accounts will not be actively exposed/published. It is really the same thing as scraping the classic API endpoints and/or author pages of WordPress.

I would highly recommend to secure your logins by adding a second factor authentication for example!

[ichderfisch]

Thanks for your answers.

First of all hiding admin user information is common issues discussed by others and within other plugins (or CMS) as well. Examples: (1) (2) If you search the web for this topic, there are lots and lots of sites and plugins to remove public exposure of admin user information or profile page, even listings in the backend for normal and privilged users. Some examples (1) (2)

Also there special plugins to just secure the Admin Account, which all might need an update, if a functionality like this might not be implemented here, for example: (1) (2)

Regarding the JSON API: Bad enough you can just iterate through the API and scrape everything. That's the reason why Plugins and Snippets exists to disable it completly or limit the functionality to authenticated user or specific informations. Also: Why do people delete user/1 or generate random user ids. Or rename wp-login and wp-admin. And why we do not name our admin "admin". And why we alter error messages admin username guessing. Or remove XML-RPC. Just to make it a little harder, obscure and become an even more unattractive goal. 2FA oder passwordless logins are given and used options. Example (1) (2)

I'm not to familiar with everything Mastodon/ActivityPub, but i assume as the plugin states on the user profile page/plugin page: Someone just has to enter the profile identifier @[email protected] to find any user, no matter he has published something or not. The Webfinger (that's how it is called?) always gives an result, right? This gives just a new entry-point in username guessing.

I might also ask for a general option to disable ActivityPub for any user of any given role, based on an option in the user profile or a dedicated permission to control ActivityPub publishing at all, but I think this might be much more effort to implement and might be achieved via customs roles and the publish_posts permission. That way I have a workaround. That's why I only care for the admin user: Currently I don't have any control at all.

It's not about my personal blog, I don't really care if anything happens over there (here I definitly just use a different account). It's a more general request to at least consider a larger rollout.

[XSized]

I completely agree with @ichderfisch

This is something that bothers me about this actually great plugin. I have removed everything that could give away the admin user. But my posts in Mastodon are done with @[email protected] and that's a big risk. I can see every day attempts to guess the admin user and login to my site. It would be great if we could change the name or the plugin would use the public name you can select in your profile.

[timnolte]

@XSized IMO you shouldn't be using your site admin account for content management and posting. I explicitly don't do this, which is that practice I have with my own real Mastodon instance.

That being said I do agree that the ActivityPub plugin should have options to enable/disable the features perhaps by user and/or role. Mastodon instance has the ability to not list admin users in the profiles directory so it seems reasonable that the ActivityPub plugin should provide a similar feature.

[XSized]

@timnolte You're right, I shouldn't. But we have the same issue for every user. The username will be published by the plugin even if you hide it.

I'm using among other things the plugin Edit Author Slug to hide the login names from URL. So instead /author/login_name the URL is /author/my_selected_name. And ActivityPub sees this changed path.

[pfefferle]

My 5 cent: I would love to stick with as many core features as possible and not to add too much things that are already there. There are already a lot of settings and the more I add, the more complicated it becomes. I am still with @mediaformat the username is a public thing, from the author page to the API! I think we should not invest in hiding it, but to harden the login, by using two factor authentication and similar methods. A lot of communities, including GitHub is using the login name aus profile identifier.

But in the end I tend to implement these features, because a lot of plugins do break these core functionalities by for example hiding author pages :(

[janboddez]

Does the plugin, right now, essentially "create" an actor/profile for every user (author and up)? Even if it is never used to author content with?

I think it could make sense to disable ActivityPub (and WebFinger etc.) for certain users or roles. I know how hard it is to implement a gazzillion UI settings ... that's why I would suggest, once more, a filter. :-D So that if a request comes in for a certain username, one could use a callback to just shortcut it and let the plugin would, I don't know, a Not Found error or something.

Or, if it must be a setting, it could be added to wp-admin/profile.php, so that [admins] could disable it there.

... by for example hiding author pages

Haha, I do this. Not because I have anything against them per se, but because they have the "permalink front" in them, always. If my articles live at /articles/<post-name>/ and I, for instance, also have a project CPT at /projects/<post-name>/, then my author URL will always be /articles/author/<me>/ (and not, e.g., the more generic /author/<me>/). The only way to set it to something else is by filtering the author_url.

[mediaformat]

Does the plugin, right now, essentially "create" an actor/profile for every user (author and up)? Even if it is never used to author content with

@janboddez it does exactly this!

[janboddez]

Just an idea:

I notice there's quite a few user_can( $user, 'edit_posts' ) calls, which makes sense, you don't want to create profiles for subscribers.

user_can() (in WP core) checks $user->has_cap(), which can be filtered. So, theoretically, it is possible to temporarily override certain users' capabilities. (Like, in a callback, one could check if the current route == "ActivityPub" and if so, return false or whatever, based on, e.g., a user ID.) But it's difficult to control (I think).

If user_can() in the plugin were replaced with a helper function which contained a filter and only then called user_can(), something like enable_activitypub_for_user which accepted a user ID, this would be a lot easier. Developers could then add a tiny bit of PHP to effectively choose who gets to "federate" and who does not.

[janboddez]

And another (and possibly better) idea: use rest_request_before_callbacks and attempt to block any requests for whatever account you don't want AP to work for.

Anyway, I commented because I was running into author page issues (see my reply the other day), but I've found a way around them, and that's good enough for my use case.

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[mundschenk-at]

Still relevant

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days.