This isn't so much a problem as it is something everyone should be aware of. The option name is RequireBuildingPrivToTrap. I don't know about everyone else, but I read that option to be am I authorized by a TC to build. That's not what is actually happening. Not being blocked from building is different than being authorized by a TC to build, and they are checked by two different methods on the player object.

You used the method player.CanBuild() to check for this. The other one is player.IsBuildingAuthed(). Your method works just fine when RequireOwnershipToTrap is true (and not bugged, see my other thread), but if you set that option to false, you can actually set traps on some in-game doors (e.g. Oxum's back door to the garage) even though technically you can't build there. The way Rust disallows building near prefab tile sets is to tell you there's not enough room to place what you want to place, not that you are not authorized to place it there. So player.CanBuild() evals to true even without the room to place it.

But, if you change the check to player.IsBuildingAuthed(), you then you go to the other extreme of not being able to place a trap on anything unless there is a TC in the area on which you are authed. I'm not sure that is desired either. 

So as it is right now, if users of this plugin set the option RequireOwnershipToTrap to false but RequireBuildingPrivToTrap to true, their players will be able to trap some built-in doors in the game. This may or may not be desirable, but IMO it is certainly not obvious. Hence the clarification.