The Boring Dev Log 2: Electric Boogaloo

Recommended Posts

Right, so a few people said they liked the content in the last ( and first ever ) Boring Dev Log, so I suppose I should make a franchise out of it. To start off with, how about a sequel?

AtherysTowns

Today, I'm going to go over the pains I've been having with the AtherysTowns plugin, specifically focusing on the permission system, as that has been the most painful part of it, causing me to rewrite the plugin from scratch.

Again, to preface this, I doubt many would get any enjoyment out of this thread. And this one in particular is more of a rant on my part, getting something off my chest about permission management in general ( not just in minecraft ).

Permission Management Is Hard

It just is. It's frustratingly hard. That's not to say that permission handling models don't exist out there, they do, but they're mostly intended for enterprise-level applications. Things like Access Control Lists ( ACLs ), Attribute Based Access Control ( ABAC ), which is itself an improvement of the Role-based Access Control ( RBAC ) approach, which can itself be used to implement Lattice-based access control ( LBAC ).

Did you understand any of that? Yeah, neither did I. Security in general is a very broad subject, requiring a lot of specialization in order to be considered an "expert" on it. I am certainly not one such person. And if you came to me and told me "Hey, maybe find an Informational Security Expert to help you out with the permission part of this minecraft plugin", I would have probably ignored you because that's too much effort for a bloody minecraft plugin.

Yet, here we are, after having written and rewritten the permission system of AtherysTowns a good dozen times, I slightly regret not having done my research better. Now that that's off my chest, let's get into the boring parts...

So How Will Permissions Work in AtherysTowns?

Before we get into the details, let's establish a few basic concepts.

Broadly speaking, we have 2 types of objects in our plugin. We have actors ( those who can execute actions ), and subjects ( objects which are acted upon by an actor ).

We also have 4 types of entities in the plugin, which is the Nation, the Town, the Plot and the Resident ( which represents a player ). A Nation contains many towns, a Town contains many Plots and Residents. There are other things which are part of these entities as well, but those are just noise for the purposes of the permission plugin and don't matter.

So then, here's the first important question: Which of these are Actors, and which of these are Subjects? The answer seems simple at a glance: Residents are actors, and all others are subjects, right? Well, yes and no. If we say that only Residents are Actors, then we have to deal with certain limitations.

Imagine the following:

Quote

The Mayor of Town A wants to permit the residents of Town B to build upon Plot C, which belongs to Town A ( the mayor's town ).

How does the mayor go about doing this? If we accept that only Residents are actors, they would have to manually permit all residents from Town B to build upon Plot C. Fine, say they do that. What if one of those residents leaves their town?

The plugin wouldn't be able tell if the resident was added because they were part of a town ( Town B in this case ), or because they were explicitly permitted, independent of any town, to change the plot.

The way to fix this, is to have a way for the mayor of Town A to permit Town B ( as an object ) to modify Plot C. But because we've already said only Residents are Actors, we can't do that.

There are a few possible solutions to this. What I've done is I've just said "Ok, so not only Residents are Actors, but also any entities which contain residents".

What this results in is the following:

Plots are Subjects

Residents are Actors

Towns are Actors AND Subjects

Nations are Actors AND Subjects

To explain it more broadly, any entity which represents a part of the world is a Subject. Any entity which represents a player ( or a group of players ) is an Actor. Any entity which represents both is both a Subject, and an Actor.

Let's go back to our initial case:

Quote

The Mayor of Town A wants to permit the residents of Town B to build upon Plot C, which belongs to Town A ( the mayor's town )

Now, because of our rework, we've made it so the mayor can permit Town B ( instead of each of Town B's residents independently ) to build upon Plot C. If a resident leaves Town B, then by definition they are no longer a part of Town B, and would therefore have no permission to change Plot C anymore.

This system, as you can guess I hope, also extends to Nations. You can imagine I'm sure many different situations where this would come in useful.

5

1

Share this post

Link to post

Share on other sites

I don't know the relevancy of my following statements but I'll put it out there for consideration's sake. How will locks work in all this? Under the old system you could do some tricky stuff like even if you were a Resident of Town A with no permissions on Plot C of Town B, you could still put a lock on a chest you had no permission to access. Additionally, there was the problem of locking a chest out in the wilderness and then a town would claim out to prevent you from ever accessing it. And to top that off their was also the headache of leaving a town with your locks left in place so neither you could retrieve your items, nor could the town have an easy way to deal with said locked chests/doors. As you've explain and from what little I can glean as a layman to this stuff it seems like this is quite complicated. Additionally, I could be ignorant to some rigorous but separate work you're already doing or have done regarding this topic. On top of the possibility that the issue of locks is being intentionally ignored for good reason. However, I just thought it might be helpful to mention this on the off chance it hadn't been considered. Thanks again for doing these. It's really nice to know that Horizons is being developed and it's nice to be able to follow its progress in a small way. I also hope these blogs help you as a dev, I know personally writing problems out can be the thing that inspires the solution to a particularly difficult or complex problem.

Share this post

Link to post

Share on other sites

I don't know the relevancy of my following statements but I'll put it out there for consideration's sake.

How will locks work in all this?

Under the old system you could do some tricky stuff like even if you were a Resident of Town A with no permissions on Plot C of Town B, you could still put a lock on a chest you had no permission to access. Additionally, there was the problem of locking a chest out in the wilderness and then a town would claim out to prevent you from ever accessing it. And to top that off their was also the headache of leaving a town with your locks left in place so neither you could retrieve your items, nor could the town have an easy way to deal with said locked chests/doors. As you've explain and from what little I can glean as a layman to this stuff it seems like this is quite complicated.

Additionally, I could be ignorant to some rigorous but separate work you're already doing or have done regarding this topic. On top of the possibility that the issue of locks is being intentionally ignored for good reason. However, I just thought it might be helpful to mention this on the off chance it hadn't been considered. Thanks again for doing these. It's really nice to know that Horizons is being developed and it's nice to be able to follow its progress in a small way. I also hope these blogs help you as a dev, I know personally writing problems out can be the thing that inspires the solution to a particularly difficult or complex problem.

The locks plugin is currently planned to be a completely separate from the Towns plugin ( and in fact, I have no intention of developing such, instead opting for a plugin from Sponge's Ore repository ), thus you are correct that it is (un)intentionally being ignored within this permission system. This is a problem that can be fixed later on, and I consider it of lower priority than many other things. For right now these are considered open questions and we can resolve them later on in the development process. Who knows, in a Boring Dev Log down the line I might mention it

Our picks

To honor the past versions of our amazing server and its legacy, we are returning the world of A'therys Ascended to your pleasure once more! Thanks to the tireless work of our beloved admin @Dannie, he has managed to pull my old build server from the depths of Minecraft limbo.

V1 Calastore

Whilst many of you use to use my build server, this will give you a chance to revisit your old builds on there. However beyond that, we have also restored the other worlds on there, including the A'therys v1 and v2 worlds. But to push the goal even further, we have also managed to bring back the A'therys Evo world.

v2/ Evo Vrovona (Capital)

Unfortunately you cannot play on the world as we did once before. All of our main resources are committed to delivering A'therys Horizons. However, in the mean time, why not take a trip down memory lane? Or even better, introduce our new and upcoming friends to the world you once knew.

As we look beyond the Horizon, to a world we all do not know and adventures that await, we can treasure the past and the legacy of A'therys Ascended.

v1 Qhul-Rahav

You can connect to the server via the Conquest Reforged client OR with vanilla Minecraft 1.12.2. You can get to this server by running the command /server old. To get permissions just ask any fellow staff member, as the server is running off my original A'therys Evo build server set up with PermissionsEX. You can easily visit all of the worlds via multiverse by using /mv list and /mvtp <world name>. Any issues please contact us via the #support channel on our discord: https://discord.gg/b7HdQVN

v1 Dorrod Muth

We will continue to work on hard on putting together and delivering A'therys Horizons, but in the mean time we hope you enjoy this opportunity to revisit A'therys Ascended.