[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


    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.


    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.)


    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.

    • 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


    I found out that I had to type my name manually but I never installed minemaniacore. I don't even know what that is.
  3. Offline


    Ok then, can you post your plugin list please
    This will help us track down the issue (as it's not a specific conflict) and fix it
  4. Offline


    Is this working on RB 860?
  5. Offline


  6. Offline


    Hello, just downloaded the plugin and it works great except for a bug I've noticed. After I place a [private] sign above a door with a player other than myself in the second line (I was protecting a door for someone as admin), the protection isn't removed when I destroy the sign. Now I really see no way to remove the protection. Thanks!
    CB860, Lockette 1.38
  7. Offline


    This must be a conflict as there is no way for Lockette to protect a door unless there is a Lockette sign in the correct position
  8. Offline


    I use this plugin on my server, and it's great! Thanks!
    mason1370 likes this.
  9. Offline


    There Is A bug where on a set of double doors that is being controlled by lockette with auto-timer engaged, a player can open one door and the other won't open. This will cause one door to be permanently open if you try to close one. Really annoying because then we have to remove the doors OR the sign, close them, then put the sign back up.
  10. Offline


    ok i installed the addon on my server and left the setting as they where when i downloaded it but when i try to acsess someone elses chest eventho im and admin it wont let me look but i can open and close doors any help please appart from that great addon
  11. Offline


    This is a conflict not a bug, someone else on your server is preventing the 2nd door from opening by user action but allowing Lockette to "close" the door
    Go in to the settings and turn snoop on
  12. Offline


    My List:
    Essentials (Geoip and Groupmanager come with it)
    MagicCarpet (added after doorglitch)
    VanishNoPickup (added after glitch too)

    Hope this helps,

    Look of Disapproval.
  13. Offline


    Well I tested it and here's how it works. I create a sign with another player's name above a door. Then I destroy that sign. When I place a new sign with no names, it says essentially Door is already private and the sign can't be placed. If I create a new sign with MY name in line in line 2, it lets me. Then when I destroy that sign, it removes the protection.
  14. Offline


    The door is not protected, Lockette conflict checks just believe it is for some reason
  15. Offline


    are you getting errors on your console when this happens? It might help the "author" (no offense, but that is who this is aimed at, not the rest of us) figure out what is happening. It would also help him if you were to post either in pastebin or in spoiler tags your list of plugins and any config files for it.

    Since it has been a week since he/she has been here, I would post that and wait until you get an answer.
    Edit: Just as a guess, it won't be a conflict though. I bet it is protecting the sign with the "creator" name instead of the name on the sign under "private".
    quickclay likes this.
  16. Offline


    This is a known conflict that was believed to be isolated to Minecart Mania Core, however it has started to show up with other plugins
    Also it can't know who created the sign and protect as such as Lockette has NO DATABASE, this means it sees what you see, if the sign is
    then it will consider noobinator the owner no matter who puts the sign up
  17. Offline


    That sounds much more detailed for an answer to his problem :) Sounds plausible to me. I think it would still be useful to know what plugins he has, what errors, what config he has. At least to find out what database is recording who placed the sign. Even conflicts are fixable if the authors wish to track it down.
  18. Offline


    OK, what part of NO DATABASE did you not get?
    Who placed the sign is used if the user does not have the lockette.admin node relevant to that object or if the 2nd line is not filled, this information is stored PURELY on the sign
    At no point is a database created, written to, read from, or in any way shape or form utilised by Lockette
  19. Offline


    Maxis, calm down. I said WHAT database. As in which plugin it might conflict with that has a database. Seriously chill. I refuse to respond to the rest of this and let you start a fight.
  20. Offline


    Do me a favor, don't tell me to calm down, it just annoys me more, also, what you see is not anger or me shouting, it's me drawing you attention to a fact that appears to have escaped you, I'll repeat it in lower case
    The error follows this pattern
    First placement goes fine, be it named or unnamed
    After breaking any following placements fail on the conflict stage, this has been put down to (by Acru) the sign being modified in the existing protection check, that was when it was just Minecart Mania Core as a known conflict
    Now it only occurs when Lockette goes to edit the sign as if the sign is named Lockette has no reason to edit the sign and so, no problems

    So, what part of this makes it a database problem, I'm not trying to pick a fight but how did you put it down to a database recording the sign in your first post, there has been nothing to support that fact.

    Somewhere after the bukkit events firing and before Lockette attempting to modify the sign there is a problem being caused by Minecart Mania and at least one of the following (list taken from Look of Disapproval's post)
    AdminChat, Essentials (Geoip and Groupmanager come with it), FirstSpawn, Jail, mobSpawner, MyHome, HelpPages, Stargate, WorldGuard, DisposalChest, MagicCarpet, VanishNoPickup
    WorldEdit - I can scratch this one as I run WorldEdit along side Lockette without any problems
    Now IMHO the likely suspects here are Essentials and WorldGuard, Essentials as it has caused issues with Lockette before and because I've heard of no end of conflicts with Essentials in general and WorldGuard because it is a protection plugin and they usually don't play nice together when they try to protect the same thing
    If anyone is using Lockette with one or more of these plugins without issue please say so so that we can shorten this list
  21. Offline


    does it work for trapdoors?
  22. Offline


    It has been requested but not implimented
  23. Offline


    ok thanks
  24. Offline


    Can you please allow other people on the signs besides just the first person to break the sign or add more signs?

    As in, if a sign says this:

    Then I can add more signs to the chest/door or break the sign if I want to remove the protection, even though I didn't create the protection sign in the first place. Basically, give full control to everyone on the sign.

    This would be especially great as an option. Perhaps a new tag, like [Owners] instead of [Private]? Anyone listed as an owner would get full rights even if they didn't make the sign.

    Thanks for the great plugin! I have been using it for a long time now and I love how it's so easy to use and has no database to worry about. Also, I sent you a little donation as thanks. :)
  25. Offline


    That would be really nice to have. What is your implementation priority for time ranges?
    If you're not having enough RL time I'd be happy to donate some code, I really like Lockette!
  26. Offline


    No but seriously. I just installed your plugin, and everything works fine.
    Except for the small error that comes up (In Game Only) whenever I place a sign above a door.
    ERR: "Lockette: Conflict with an existing protected door."
    Only I havent been able to protect a door yet, soooooo
  27. Offline


    This has been answered several times in the last few pages.... There are some issues using this with a couple other plugins. You can make it work by putting your name on second line of sign when placing it.
  28. Offline


    Hiya, I had some players and staff on my server report that chest protection can be removed by using a piston to move the sign on a chest, etc. to another block. Thereby allowing anyone to access it, and remove items. Is this a known issue already?
  29. Offline


    I'm not sure if this is considered a bug, however, this actually took me a while to work out, signs don't attach to chests if placed next to it, it will if It's in front of it... Just saying.

  30. Offline


    Nope, you might want to get in touch with whoever is managing that plugin and have them either work in Lockette specific support or block sign movement entirely
    LlmDl likes this.
  31. Offline


    Is it possible to make it so people can only add their own name to the sign? i have alot of users locking multiple names.

Share This Page