[SEC] Lockette - Simple chest and door lock, no databases! [Moved to BukkitDev]

Discussion in 'Inactive/Unsupported Plugins' started by Acru, Feb 14, 2011.

  1. Offline

    Acru

    Lockette - The sign-based container and door lock for Bukkit! - by Acru Jovian

    ElgarL has been assigned as the current maintainer of this project, please forward any important issues to him as well. This post is abandoned, but proceed to BukkitDev for updates.

    Download it at BukkitDev! (Alternate) (JAR) (Source), also view the Change Log on BukkitDev.



    Supported external plugins:
    • Permissions - Permissions/Groups
    • GroupManager - Permissions/Groups
    • PermissionsBukkit - SuperPerms/Groups
    • PermissionsEx - SuperPerms/Groups
    • bPermissions- SuperPerms/Groups
    • Towny - Groups/Zones
    • SimpleClans - Groups
    • mcMMO - Groups (Disabled by default now, due to issues.)
    • Factions - Groups
    • LWC - Zones
    • Register - Economy
    Alternate languages included:
    Confirmed compatible plugins: ColorSign, SpeedSign.
    Conflicting plugins: ChestShop, Most sign editors!


    The active Lockette information page will commute to BukkitDev soon, but the forum thread is still the best place for discussion.



    Overview:

    The purpose of this plugin is to restrict access to the contents of chests, dispensers, furnaces, and doors without the use of a database to track containers.

    To use, simply place a signpost on the floor directly beside a chest or other container to be locked. Enter [Private] as the first line. Your own name will automatically be entered on line 2 as the chest owner. Optionally type in the full names of two other users allowed to access the chest's inventory on lines 3 and 4.

    When done correctly, the sign will automatically fix itself to the side the target chest, protecting it from unauthorized access! Only the chest's owner can then break the sign or chest. (Warning: Anyone with permission to use WorldEdit commands or similar can circumvent the protection by removing the sign.)

    [​IMG]

    Additionally, you can enter [Everyone] on lines 3 or 4 instead of a user name to allow everyone access to the contents of a private container, or [Operators] to allow ops access. If a Permissions plugin is available, you can use groups like [Moderator] or [Admins] or others as defined in the Permissions settings files.

    The owner of a container can add more users by placing additional signs beside the container with the heading [More Users], where lines 2-4 specify the names of the additional users. You can edit the users on previously placed signs by right clicking the sign, and using the command '/lockette <line number> <text>' to change it.


    Working with Doors:

    To protect a door, you can use the same method as protecting a container, the sign will attach to the door automatically. In addition, you can attach a [Private] wall sign to any side of the blocks just above or just below a door. For double doors only one side needs a sign. Door support is enabled by default in the config file.

    Once a door is protected it will only open for someone listed as a user, and will not respond to redstone power or switches unless [Everyone] is listed as a user. Iron doors which usually won't open from clicking will work just as wooden doors. In addition, double doors will open together automatically!

    You can also use [More Users] signs as with containers, with the caveat that the sign cannot be placed on the block above the door if the [Private] sign is not above the door as well! (This is done to prevent a security uncertainty issue.)

    Protected doors will be closed automatically if a timer is set. A timer can be set globally with a configuration option, or individually for each door by using the tag [Timer: #] on line 3 or 4 of the [Private] sign, where # is the number of seconds that the door should remain open. If the timer is set to 0, this means the door will never automatically close. If no timer is specified, protected doors will use a global timer set in the configuration file. If the server is shut down cleanly any open doors will be closed, but in the event of a server crash while a door is open, it may remain so. Note that the initial state of a door is assumed to be closed.

    Care must me taken to place protected doors on a stable block. Building a door on sand, gravel, leaves, TNT and et cetera are allowed by the plugin, but cannot be secured fully. :3 Additionally, it should be noted that most status messages still refer to locked blocks as containers, so for the purpose of simplicity, doors should be considered as a type of container.


    Features:
    • No passwords or databases needed!
    • Permission checks run in constant time, no matter how many protected containers.
      • One owner and up to 11 additional users supported. (17 for double chests!)
      • Allows access to [Everyone] while still protecting the container from vandalism.
      • Allows group names in conjunction with many other plugins.
    • Special powers for ops or admins, configurable with permissions.
      • Reports when an admin does something naughty.
    • Protects single and double chests, dispensers, and furnaces.
      • Explosion and block-break protection for the protected container and sign.
        • Option to protect all containers from explosions.
    • Full support for doors, both wooden and iron!
      • Double doors are handled automatically, with no redstone.
      • Doors can be set to close automatically, via a timer setting.
      • Redstone hacking is disabled for protected doors.
    • Prevents creation of chests larger than 2 blocks.
    • Informative or helpful messages when interacting with containers.
      • The first time a chest is placed, a help message will be shown.
      • Types of messages shown are configurable in settings.
      • Additional language support.

    Advanced Setup (Permissions) (open)

    Advanced Setup:
    There are a few things you can now customize in the configuration files for the plugin, found in the plugins/Lockette folder. After running the plugin for the first time, two files will be created, config.yml and strings.yml. The first holds the following settings:
    • enable-permissions - Allows the use of permission nodes to specify who can do what. If this is disabled, groups will still be used but admin status is taken from the ops file. Defaults to false.
    • enable-messages-* - Enables or disables groups of messages listed in the strings.yml file. Not counting the broadcast ones.
    • broadcast-*-target - Sets the group or player that specific broadcast messages should be sent to. This can be set to "" for no one.
    • explosion-protection-all - Enabling this extends explosion protection to all containers on the server, not just [Private] ones. Default is disabled.
    • allow-admin-bypass - Allows admins to go though any protected door. Default is true.
    • allow-admin-snoop - Allows admins to peek into chests owned by other people. Default is false, and this setting is recommended! A broadcast message will be sent each time an admin snoops in a protected container where the admin doesn't have permission to. The message will be sent to a player or group as specified in another option. Admins can still break protection on chests if this is disabled, however.
    • enable-protection-doors - Enables support for private doors, defaults to true.
    • default-door-timer - Sets the door closing timer for all protected doors on the server, unless overridden by a specific sign. Defaults to 0, which disables the door closing timer.
    In the strings.yml file, you can set alternate language tags for [Private] and such, in ANSI format. If you need characters not in ANSI then you might try UTF-8 format, though it seems bugged tight now. The default alternate tags are in French, but server ops are free to translate the whole file into the language of their choice. If you do this, please share it back to me~ :3 If you want to disable only a specific message, you can set it to "", the empty string. Admins can use the command '/lockette reload' after editing the configuration files, to reload them.

    If a Permissions plugin is not available or the enable-permissions option is set to false, Lockette will use the ops file to determine who are admins. Admins can break the protection on any chest, and look inside protected chests (only if the related option is set), as well as reload the plugins configuration files. All non-ops will be able to create protected containers for themselves.

    If a Permissions plugin is available and the enable-permissions option is set to true, the following nodes will be used instead of the ops file and are included by default in the '*' node:
    • lockette.user.create.* - Permission required to create a protected container or door. Possible sub-nodes include chest, dispenser, furnace, and door. (The permission lockette.create.all is still supported, but obsolete.)
    • lockette.admin.create.* - Allows admins to create containers and doors for other users. Possible sub-nodes include chest, dispenser, furnace, and door. Leave line 2 blank for the default behavior or enter the name of your choice. Capitalization matters.
    • lockette.admin.break - Allows breaking protection on containers.
    • lockette.admin.bypass - Allows opening of any locked door.
    • lockette.admin.snoop - Allows peeking in protected containers. (The setting allow-admin-snoop must be true.)
    • lockette.admin.reload - Allows use of the reload command.

    Technical Information (open)

    Technical Information:

    This plugin has been tested and shown to be working for many builds of CraftBucket though a number of the more recent builds had a serious issue, so I'm suggesting a minimum build of 561 now. If you update past what is listed in the post's title and the plugin seems to break, it is probably not my fault. Post a note anyway and I'll see about fixing. I'll try and keep up with the new recommended build system, but for latest builds that break things, you should expect some time to pass before I take care of the issue, as this plugin is now mature. :3

    If there are multiple containers by the placed sign, the plugin will use the NESW rule to choose the first container that is not yet private. To elaborate, the plugin will check to the north of the sign first, and if no container or door is available to the north, it will continue checking clockwise around the sign.

    Due to the current implementation of the explosion event, this plugin will cancel all explosions that would damage the container or sign, rather than just remove the container and sign from the blocks to be damaged. Canceled explosions still knock signs off the walls. Canceled explosions leave signs looking blank, but this is just a graphic glitch, reconnect to fix.

    Bonus: This plugin will prevent chests bigger than 2 blocks from being created via glitches. (Again, this could be circumvented using WorldEdit commands, so take care who has access to such a plugin.)

    This plugin was inspired by the old hmod plugins Lock by Roman "kingseta" Pramberger and ChestCapsule by Fernando "Fergo".

    Hooking into Lockette (open)

    Hooking into Lockette:

    If you are a plugin author and want to connect to Lockette, you can use a public static function to get information about the protected status of a block.

    More info later, perhaps, but if you need the details now then go poke through the source~

    Future Possibilities:

    There are a number of things that have been suggested, and they tend to be added to the list below if I think they might be a good idea. However, some sort of locked container limit is requested often but this is not possible without a database to track the number of locked containers someone has. All things considered, this will not be supported. On the up side, without a database you can have literally millions of locked containers without any sort of lag, and there are permissions to restrict who can create locked chests. Perhaps only allow Moderators to create locked chests for other users, if you don't want to allow infinite locked chests.

    Aside what has already been implemented, the following may or may not appear in future versions:
    • Furnace/dispenser clusters, protected by a single sign.
    • [Log] sign to list recent users of a container or door.
    • iConomy fee for protecting containers/doors.
    • Worldguard connection.
    • [Protected] tag for viewing only.
    • Specific time range that doors can be opened.
    • DataLog plugin support.
    • More types of protected blocks, such as brewing stands.
    If you want any of the above features sooner than never, let me know! However, I currently see Lockette as functionally complete, for the most part, in that it already has all the functionality it needs. Future updates will mostly be to account for changes in Minecraft and Bukkit.


    Final Note:

    Please leave a reply if there are any bugs or suggestions, and if you like this plugin you can click the like button at the bottom of this post~ Thanks to those few that have donated! [​IMG]
     
  2. Offline

    Flatliner

    There's a problem with lockette and minecartmania with the latest version of mm. I think afforess is looking at it (I did let him know that it broke lockette) but I figured I'd a drop a post here in case anyone else discovered their sign placement wasn't working (keeps saying conflicting with existing doors) .
     
  3. Offline

    NVX

    Yup, that was the issue I was having. Thanks for posting here, probably would have missed it in the MM thread :)
     
  4. Offline

    YukonAppleGeek

    Could you add a option to allow cretin groups in Permissions? Like "[Private Group]" then the groups.
    EDIT: Never mind i found it :D
     
  5. Offline

    Zorkin3

    I have a problem with Lockette, permissions (2.x - the 3.x doesn't work for me) and multiworld (MultiVerse) on bukkit 818 (OS: debian linux). I set a permission (lockette.user.create.* ) to create a chest to only one world, but users can privatize chests in other worlds too. This is probably issue with new 1.6 multiworld system. I need users to privatize chests only on creative worlds and not on PvP world.

    Or am I doing something wrong? Thanks, Martin.
     
  6. Offline

    Maxis010

    This is a Bukkit issue
    When they disabled Multiworld they caused a lot of problems restoring it, to be specific Permissions isn't reading the other worlds so no doubt you granted permissions on your main world which is why it is bleeding over
    Back up your server and update Bukkit to 820
     
  7. I'm having issues with this plugin. Only me, as the server admin, can lock containers, and nobody else can. I'm using Permissions and i've added the "lockette.user.create.*" node to the default group, but still it doesn't work. I'm with the 818CB.
     
  8. Offline

    Maxis010

    Do you have Multiple worlds, have you granted the permission on the default world
    Q1: Yes, Q2: No, then you have the same problem as the last guy, update to 820 and try again

    If that doesn't fit your situation then can't help you I'm afraid, wait for other replies
     
  9. Offline

    HockeyMike24

    This would be awesome with the new trap doors.
     
  10. Offline

    Southpaw018

    Acru, I know you've said that you consider Lockette feature complete, but could you add an option to protect switches, levers, and buttons?
     
  11. Offline

    defiant810

    Hmmmm... I appear to be having troubles with Permissions...

    Is this version compatible with Permissions 3.1.1? Whenever I try to lock a sign for a group called [Directors] is says: "Player [Directors] is not online."

    Im running CB818 if that helps...
     
  12. Offline

    Maxis010

    Line 2 of the main sign will always assume it's looking for a player, however the group should still have access
    CB 818 is buggy with multiple worlds, move to 820 at least which should fix some MultiVerse/Permissions problems
     
  13. Offline

    Kaosthe1st

    @Acru Will you be considering adding hatch support?
     
  14. Offline

    Novae7

    when you write your name in line 2 it works with MM
    Code:
    [Private]
    Novae7
    line3
    line4
    works for me
     
  15. Offline

    Acru

    Oh good~ Was puzzling over why you were having the issue, glad someone got it pinned down. :3

    The best way I think would be to issue a temporary lockette.admin.break permission to the attackers. I'm not sure how well that would work though.

    You can already hide signs in more places than the video mentions.

    For instance you could place the sign on the left or right side of the block that the door is standing on, so its hidden between the floor and the wall.

    Did you enable use of permissions in the config.yml file? If you are an op, that would explain it. (I had to make this false by default, as too many people had permissions installed but didn't know how to give themselves the lockette.user.create.*)

    This is being considered.

    You could use lockette as it is but not give permission to lock anything else?

    As I have said before, doing so is a bit pointless as there are various ways to hack into redstone circuits. What you could do is put the switches behind a Lockette locked door, however, assuming you have a cuboid area protection too so people can't dig through walls. :3

    And I recognize that old dogcow icon, lol...

    Actually this is normal, intended as a warning that the owner you are assigning isn't a known player. Note however that non-player owners won't be able to modify the protection, only admins.

    I am considering yes.. I should put it in the main post, people keep asking~ lol

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 8, 2016
  16. Offline

    Southpaw018

    Understood, and thanks :D (Also, thanks once again for the help on Cenotaph. I'm currently awaiting approval for public release.)
     
  17. Offline

    Maxis010

    MM Author (can't spell his name) picked up a copy of Lockette and is working on tracing and fixing the conflict
     
  18. Offline

    oliverw92

    Could you make it so you support multiple 'groups' in these options:

    We want it so our [admins] and [moderator] group both get those messages.


    I was also wondering would you consider supporting my DataLog plugin for logging when someone tries to access a chest that isn't theirs/when an admin breaks or looks in a chest that isn't theirs? It's only takes 3 lines of code and then one more at every location you wish to log from. Theres more information here: https://github.com/oliverw92/DataLog/wiki
     
  19. Offline

    Maxis010

    If Permissions 3 is supported then you can either A add your admins to the mod group as well or B create a 3rd group called Lockalert and add your admins and mods to that
     
  20. Offline

    oliverw92

    Interesting. Unfortunately some plugins aren't updated to Permissions v3 so I guess i'll have to wait
     
  21. Offline

    johndom

    I found a small bug for it =[ just started doing it and I tried re downloading, basically on my own server my rank is "owner" and i have '*' permissions but i cant access other peoples chests or even create private signs for them, it just goes back to my name instead of theirs, example: i make a sign for bubbajubba with [private] but it then chages back to johndom.... the "Admins" rank can make signs/ delete others signs and access but I cant and WE BOTH HAVE '*' so pllleeeaaaseee can u fix this please, thank you :D :)
     
  22. Offline

    Maxis010

    This is a permissions problem, not a Lockette problem, check that you aren't cancelling out your * permissions and post for support over there
     
  23. Offline

    Acru

    I'll have a look-see at it.
    And what Maxis said seems easier than trying to add multiple reporting groups to Lockette. :3
    Anyone had issues with permissions 3 and Lockette btw, or can anyone confirm otherwise?

    Don't forget you need to turn on the use of permissions in the Lockette config.yml, otherwise it will default to using ops file for admins, and everyone else can only make chests for themselves.

    Use:
    enable-permissions: true
     
  24. Offline

    Daniel Heppner

    You should be able to protect portals and hatches. Just a suggestion. :p
     
  25. Offline

    Acru

    Hatches have been suggested many times already, lol.

    Portals, well, I'm not sure how I could protect those unless bukkit team adds some event hooks for built-in portals.
     
    Daniel Heppner likes this.
  26. Offline

    johndom

    enable-messages-help: true
    broadcast-snoop-target: '[Everyone]'
    broadcast-reload-target: '[Admins]'
    broadcast-break-target: '[Everyone]'
    enable-messages-error: true
    enable-messages-user: true
    enable-messages-owner: false
    enable-messages-admin: true
    enable-protection-doors: true
    default-door-timer: 0
    explosion-protection-all: false
    enable-permissions: true
    allow-admin-bypass: true
    allow-admin-snoop: true

    this is the config file and permissions is-

    Newbie:
    default: false
    info:
    prefix: '&e[Newbie]&f'
    suffix: '&f'
    build: false
    inheritance:
    permissions:
    - 'essentials.spawn'
    - 'essentials.list'
    - 'foo.*'
    Builder:
    default: true
    info:
    prefix: '&2[Builder]&f'
    suffix: '&f'
    build: true
    inheritance:
    - Default
    permissions:
    - 'essentials.spawn'
    - 'essentials.protect'
    - 'essentials.list'
    - 'essentials.msg'
    - 'essentials.balance'
    - 'essentials.pay'
    - 'essentials.sethome'
    - 'essentials.home'
    - 'foo.*'
    Admins:
    default: false
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'
    build: true
    inheritance:
    permissions:
    - '*'
    Owner:
    default: false
    info:
    prefix: '&4[Owner]&f'
    suffix: '&f'
    build: true
    inheritance:
    permissions:
    - '*'
    ##
    ##
    # Users denote which users are included in which group.
    # TheNo1Yeti is in the Admin group
    # Herpina is a member of the Moderator group but also has access
    # to the herp.derp permissions
    # Derpina is a member of the admin group but does not have access
    # to the derp.derp permission node
    # Users can also have a prefix and suffix as seen with Herpina
    ##
    users:
    johndom:
    group: Owner
    permissions: '*'
    info:
    prefix: '&4[Owner]&f'
    suffix: '&f'
    vivaledead:
    group: Admins
    permissions:
    - '*'
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'
    xRooooosta:
    group: Admins
    permissions:
    - '*'
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'
    davidp:
    group: Admins
    permissions:
    - '*'
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'
    lilrezwavy:
    group: Admins
    permissions:
    - '*'
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'
    flintstack:
    group: Admins
    permissions:
    - '*'
    info:
    prefix: '&c[Admin]&f'
    suffix: '&f'

    I Tried making the config file with permissions true but it still doesnt work.... =[


    oh and dont worry, the permissions are in correct format ect...I triple checked with YAML Parser :)

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: May 8, 2016
  27. Offline

    Maxis010

    Well there is your problem, you are declaring the * permission on a group and user level WHICH CANCELS THEM OUT
    And I see a format error, if you are keeping user level permissions then change
    users:
    johndom:
    group: Owner
    permissions: '*'

    to

    users:
    johndom:
    group: Owner
    permissions:
    - '*'

    With spacing ofc so the YAML parser isn't infallible
     
  28. Offline

    defiant810

    Sorry I took so long to reply.

    I took your advice and updated to CB820, but the problem is persisting. Also, were you stating in your post that even though it says the player doesn't exist, the group will still have access.

    Sorry for my confusion.
     
  29. Offline

    Maxis010

    Yes, it works like this
    You create the sign
    [Lockette]
    [Everyone]
    Lockette runs a Perm Check
    Permission True
    Lockette looks for the player [Everyone]
    Player Not Found
    Send Message
    Anyone accesses the chest
    Lockette sees group [Everyone]
    Allows access

    tl;dr Lockette will always treat the 2nd line as a player when the sign is created or someone tries to break/edit the sign but will treat it as a group when the chest is opened
     
  30. Offline

    defiant810

    OK thanks
     
  31. Offline

    johndom

    Thanks for the reply and I deleted the '*' on the users and left the '*' permissions on the group and yes i did it as this
    permissions:
    -'*' but I did pr -reload and it still doesnt work :/ is there a bug in this plugin?
     

Share This Page