QUESTION : trusting a fake player inside a colony

Question

QUESTION : trusting a fake player inside a colony

gd71 opened this issue 8 years ago · 29 comments

Hello,
trying to have an ender IO killer joe working for a kind of mob farm
(in the sewers of course... ;) )
I read that a fake player name is implemented within ender io (EioKillera) but didn't found any way to add it in the permissions settings of my townHall.
This should allow it to make damages to mobs

marvin-bitterlich · Answer 1 · 2017-02-22T07:48:14.000Z

I think our current system only works for real players. And names who were never online do not work.

Supporting fake players is a good idea though

Raycoms · Answer 2 · 2017-02-22T11:21:39.000Z

Names who were never work do work for me inside intellij. idk if it changes outside. 2017-02-22 4:48 GMT-03:00 Marvin Hofmann <[email protected]>:

…

I think our current system only works for real players. And names who were never online do not work. Supporting fake players is a good idea though — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y4n7_DE8gZ6-QLB_kOT3qmAg_Qrlks5re-g_gaJpZM4MH6Eb> .

marchermans · Answer 3 · 2017-02-22T11:28:28.000Z

A fakeplayer is also a custom class in forge, so a simple instance of might do the trick

Raycoms · Answer 4 · 2017-02-22T11:41:03.000Z

Ah then putting instance of player || fakePlayer should do the trick. 2017-02-22 8:28 GMT-03:00 Orion <[email protected]>:

…

A fakeplayer is also a custom class in forge, so a simple instance of might do the trick — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y2AIM8t_INpfcXqWYCgdLOyWktpMks5rfBvcgaJpZM4MH6Eb> .

gd71 · Answer 5 · 2017-02-22T23:39:39.000Z

Understood that forge definitely got the power :)
They should implement a kind of register method for all kind of fakeplayers (even subclass) storing at least owner UUID's...
This way, enderIO or other mods could get rid of their getOwner like methods thanks to forge providing a common way to identify these objects
Not sure to be skilled enough to convince them as I probably miss some other side effects (and unfortunately I'm not a java developer)
Anyway, very interesting discussion but doesn't answer for now on how to interact efficiently with other mods
I would suggest the compromise with kind of generic instanceOf and getMethod in the mean time but it is up to the Minecolonies guys to decide about

LexManos · Answer 6 · 2017-02-23T00:38:09.000Z

Entity.getUniqueID() all you need and no extra custom API. Modder just need to set it correctly when they make their fake players.

Raycoms · Answer 7 · 2017-02-23T00:46:27.000Z

Unfortunately, when the player wants to add the fakePlayer (atm) he only has the name. Probably the best thing to do would be a "addFakePlayer" tool which adds an entity on right click. 2017-02-22 21:38 GMT-03:00 LexManos <[email protected]>:

…

Entity.getUniqueID() all you need and no extra custom API. Modder just need to set it correctly when they make their fake players. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y7nid_8NsX3Dfn_jS7Zewns_0Gfwks5rfNTygaJpZM4MH6Eb> .

LexManos · Answer 8 · 2017-02-23T00:51:15.000Z

The name is good enough, well the entity. You can get the UUID which is what people should be saving from the entity if they saved it right.
As I said in the other thread you could also just have the damn thing checking the permissions GIVE YOU THE UUID or some method of whatever it indexes its permissions by.

But, the FakePlayer for the block SHOULD use the UUID of the person who placed it so then you just need to give yourself permission not any random fake player username.

Raycoms · Answer 9 · 2017-02-23T00:57:16.000Z

The problem is that we rely on the player to add a fakePlayer as allowed interactor to the colony. Currently, they add him by name. If I can add him with the name the player used + the uuid of the player adding the entity I would be good as well. Or I could let the players add the fakePlayers with a toolRod on right click where I'd have the entity, name and UUID. Besides that I have no ID how I could get the UUID from the name on player adding it. 2017-02-22 21:51 GMT-03:00 LexManos <[email protected]>:

…

The name is good enough, well the entity. You can get the UUID which is what people should be saving from the entity if they saved it right. As I said in the other thread you could also just have the damn thing checking the permissions GIVE YOU THE UUID or some method of whatever it indexes its permissions by. But, the FakePlayer for the block SHOULD use the UUID of the person who placed it so then you just need to give yourself permission not any random fake player username. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y-D8zmlq6RWxyzArq1JPFappsNShks5rfNgDgaJpZM4MH6Eb> .

Raycoms · Answer 10 · 2017-02-22T20:57:57.000Z

Hello after some discussion etc we decided to not implement this feature.
If you allow a fakePlayer to your colony you have to add it to your colony but that means that every other player can use that fakePlayer to grief you.

EnderIO should actually implement the fakePlayer with the placers name to support this kind of behavior.

Please report this to enderIO.

gd71 · Answer 11 · 2017-02-22T21:15:28.000Z

hmmm,
yep you're definitely right, I had no thought about this case.
Thanks anyway for taking the time to think about it!

Raycoms · Answer 12 · 2017-02-22T21:25:11.000Z

But like I said, report the error to enderIO and tell them about the problem of accepting it globally. 2017-02-22 18:15 GMT-03:00 gd71 <[email protected]>:

…

hmmm, yep you're definitely right, I had no thought about this case. Thanks anyway for taking the time to think about it! — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9yy93EiDMZYslVaJN2GXofSeOftjKks5rfKVxgaJpZM4MH6Eb> .

gd71 · Answer 13 · 2017-02-22T21:30:20.000Z

done it ;)

HenryLoenwind · Answer 14 · 2017-02-22T22:16:25.000Z

Ender IO supports the Forge permission system for all its machines. In addition, all fake players have a getter for the owning player (that API was proposed some time ago for Forge, but nobody wanted to actually PR it...).

gd71 · Answer 15 · 2017-02-22T22:25:16.000Z

A bit more complex but still feasible ?

Raycoms · Answer 16 · 2017-02-22T22:28:18.000Z

Forge doesn't really like FakePlayers with static names.

MinecraftForge/MinecraftForge#3723 (comment)

They feel like all FakePlayers should have the name of the owner to recognize them.

HenryLoenwind · Answer 17 · 2017-02-22T22:38:29.000Z

Typical Lex. Ask the wrong thing and he won't be helpful.

He's right. You don't need a list of all fake player usernames. That list does not give you any more information than an instanceof check. Also, that list is not complete. It will only contain fake players that are not subclassing Forge's fake player and as such can be generated by the factory. But many fake players will need to override some methods, so they will not be in that list.

If you want to know which real player a fake player belongs to, then you need the player's UUID. The username is useless for that; it should absolutely never used for anything (except looking up the UUID when an admin enters it as part of e.g. a command). Usernames can be changed nowadays, that's why we have UUIDs now.

Raycoms · Answer 18 · 2017-02-22T22:41:52.000Z

Yeah, we know that. But when players want to add fakePlayers to their colonies they can't enter the UUID of that fakePlayer they only enter the fakePlayer username. And how might we be able to check if that username belongs to a fakePlayer? We actually need to be able to know if the fakePlayer trying to change anything belongs to a player + if the player wants him to be able. 2017-02-22 19:38 GMT-03:00 Henry Loenwind <[email protected]>:

…

Typical Lex. Ask the wrong thing and he won't be helpful. He's right. You don't need a list of all fake player usernames. That list does not give you any more information than an instanceof check. Also, that list is not complete. It will only contain fake players that are not subclassing Forge's fake player and as such can be generated by the factory. But many fake players will need to override some methods, so they will not be in that list. If you want to know which real player a fake player belongs to, then you need the player's UUID. The username is useless for that; it should absolutely never used for anything (except looking up the UUID when an admin enters it as part of e.g. a command). Usernames can be changed nowadays, that's why we have UUIDs now. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y3y59rTg74ON0LD8SluEtOGm7ZuUks5rfLjlgaJpZM4MH6Eb> .

Raycoms · Answer 19 · 2017-02-22T22:43:03.000Z

We actually store the UUID and username in the colony as "trustable" and update the username if the user changes it. But how can we get the UUID of the fakePlayer when the player enters it in the gui?

HenryLoenwind · Answer 20 · 2017-02-22T22:43:49.000Z

Yes, exactly. That's why Ender IO provides the UUID of the owner: https://github.com/SleepyTrousers/EnderIO/blob/1.10/src/main/java/crazypants/enderio/machine/FakePlayerEIO.java#L55-L59

Just one nitpicking: If a user didn't want a block they placed to work, they wouldn't have placed it in the first place, would they?

HenryLoenwind · Answer 21 · 2017-02-22T22:45:10.000Z

Feel free to PR this code (I'd recommend to either have a UUID field and a setter or return null be default, the first one will work with factory fake players, the later requires subclassing) to the Forge fake player.

Raycoms · Answer 22 · 2017-02-22T22:48:09.000Z

The Problem with this is that we would have to handle every mod which provides fake players separately. Some of them will provide a getOwner some of them not. So we will have to create an extra method to check if enderIO is installed and if the fakePlayer executing is of your fakePlayer kind and if the owner is trusted in the colony. 2017-02-22 19:45 GMT-03:00 Henry Loenwind <[email protected]>:

…

Feel free to PR this code (I'd recommend to either have a UUID field and a setter or return null be default, the first one will work with factory fake players, the later requires subclassing) to the Forge fake player. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGI9y3Mu1VAN0u4yDa3qfjz-mtUvtzI2ks5rfLp2gaJpZM4MH6Eb> .

LexManos · Answer 23 · 2017-02-23T11:46:11.000Z

#645 (comment)

marvin-bitterlich · Answer 24 · 2017-02-23T13:09:17.000Z

@LexManos Am I understanding that correctly that FakePlayer.getUniqueID() should return the owners UUID?

marvin-bitterlich · Answer 25 · 2017-02-23T09:10:01.000Z

@LexManos The preferred way would definitely be what you are suggesting. The question is: If we have a fakeplayer, how do we get the owners UUID? How do we do this consistently and not on a mod by mod basis? What would forge recommend there?

gd71 · Answer 26 · 2017-02-23T18:24:08.000Z

I can be wrong but seems like enderIO is not instantiating FakePlayer the way Forge aim to.
Not using the FakePlayerFactory which provide registering and mapping of a gameprofile given in parameter ... leading to possible inconsistent getUniqueID
I may be wrong and don't want to pollute more the discussion

HenryLoenwind · Answer 27 · 2017-02-23T21:03:55.000Z

As I wrote above...:

It will only contain fake players that are not subclassing Forge's fake player and as such can be generated by the factory. But many fake players will need to override some methods, so they will not be in that list.

Raycoms · Answer 28 · 2017-02-26T23:02:56.000Z

@HenryLoenwind we made some additional tests.
[16:58:54] [Server thread/INFO]: Couldn't get player of FakePlayer: [Wissi's Killer Joe] with UUID: 3baa66fa-a69a-11e4-89d3-123b93f75cba Owner Id is: b5a93d5b-38fc-4df2-98a7-0b3c7cd7cd0c

The Id of the KillerJoe is different than the ID of its owner. As far as I understood lex, the id of the killerJoe should be the same in order to identify him correctly?

marvin-bitterlich · Answer 29 · 2017-02-27T09:32:34.000Z

@LexManos can you help us with that?

Share to