• Resolved danielgm

    (@danielgm)


    Make it configurable, perhaps, but I think in most cases third-party developers given access for technical troubleshooting are not meant to have read access to the user base of a WordPress install so it seems the default should be blocked.

    In many countries now you are not supposed to give third parties access to user data which they have nothing to do with and not without signing a contract with them even if they do, etc.

    Blocking users.php would also block the far reaching access otherwise possible through popular plugins like User Role Editor.

    plugin-install.php and theme-install.php should probably also be blocked by default as the typical use case would seem to be asking third-party devs to look into problems with existing plugins or themes rather than asking them to install new themes and plugins on behalf of the owner.

    After all, if a WP owner doesn’t know how to install a plugin himself, we can assume he also doesn’t know how to install your plugin in order to let others do it.

Viewing 7 replies - 1 through 7 (of 7 total)
  • @danielgm,

    It’s a valid concern to protect users data.

    But, what if someone wants to deal with users data only? Then, how temporary user will help site owner in this case?

    It’s not just site owner don’t know how to install a plugin or theme. But, many times, site owners creates a temporary user for developer and ask them to setup a site. So, in this scenario, developer has to have an access to add new plugin/ theme in order to setup a site.

    Do you think if we allow Temporary User to add new plugin/ theme, it will create any issue?

    What do you think?

    Thread Starter danielgm

    (@danielgm)

    Oh, that’s right regarding plugins and themes. I forgot about the use case of someone setting up the whole installation for the owner. But this is a high-trust scenario anyway.

    It seems the main scenario is some plugin dev is given access to look into a problem with his plugin on the owner’s site.

    In that case, allowing access to plugin installation means the third party can install a backup plugin and walk away with the whole database and every file in the installation and the owner wouldn’t even know this happened.

    Even staging sites often contain significant intellectual property and/or user data.

    You’re already restricting a few things for temporary users such as adding or deleting users which are not explained on the plugin settings page. I think there should be an explanation about these restrictions on that page.

    Perhaps you could then present additional checkboxes when an admin temp login is created like so:

    1) I fully trust this party (blocks only plugin itself, user editing/deleting)
    2) Disallow plugin/theme installation
    3) Disallow users.php
    4) Disallow popular backup plugins already installed

    With a notice that other plugins may also be exposing private information or providing file level access and a hook for developers to add those to the block list.

    What do you think?

    @danielgm,

    Yeah..we are restricting few pages being accessed by Temporary User by default as you mentioned.

    You made a valid point about the plugin installation. If we consider the general scenario (except high-trust scenario), we can restrict plugin/ theme installation page from being accessed by Temporary User.

    We can definitely offer list of pages which we should restrict for Temporary User at the same time question coming is that won’t it create unnecessary confusion for admin to set this plugin. What’s your thought on this?

    How about adding restriction to those pages by default like we have already added for edit/ delete user and deletion of plugin page itself?

    We can definitely provide a hook for developers, such that they can add more pages into the restricted pages list.

    BTW, I appreciate you for all your efforts for digging deeper into this plugin and your feedback to make this plugin more secure.

    Thread Starter danielgm

    (@danielgm)

    Yes, I also think higher protection should be the default given that the main use case is the low trust one. Really, if an owner needs to give away plugin installation privilege, no plugin can protect him, and he should have a contract with the third party.

    Only the admin role is relevant, as the next highest role is editor and they cаn’t do anything critical. The admin role is what the external dev would ask for to help and it is what he needs. Just not all of it.

    Maybe you could make a fake user role “Administrator with safety” available (usermeta _wtlwp_trust = 0) as the default admin role and the normal administrator (usermeta _wtlwp_trust = 1) can only be added to the available roles once the owner has checked a box that he understands that this means that that person could make a copy of his entire site in just a few minutes and that he ought to have a contract with that person.

    I don’t see any reason ever for a temporary user to be able to create other temporary users, delete existing users, or your plugin (which would turn all temporary users into permanent users) so those existing restrictions should remain non-configurable, I think, to protect owners from their own bad judgment.

    • This reply was modified 6 years, 8 months ago by danielgm.

    @danielgm,

    Create a fake user “Administrator With Safety” seems a good option for now.

    Do you see any other options to get rid of this scenario? We will think about different alternatives of this and will be incorporated into plugin.

    Don’t hesitate to give your feedback/ suggestion. We will be happy to hear from you.

    Thanks!

    Thread Starter danielgm

    (@danielgm)

    Do you see any other options to get rid of this scenario? We will think about different alternatives of this and will be incorporated into plugin.

    Not at the moment, no. Looking forward to your next updates!

    @danielgm,

    Ok. We will work on this and incorporated in one of the release of Temporary Login Without Password plugin.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Further restrict access for temporary admins’ is closed to new replies.