GroupOptions - PermissionCheck not working properly

[Darlelet]

What behaviour is observed:

When option GroupOptions->enablePermissionCheck is enabled through config file, as soon as the user connects his parent group is set to registeredPlayerGroup, using world context.

What behaviour is expected:

The parent group should be set "globally", without using any context, so that this feature is fully compatible with existing permissions plugins.

Steps/models to reproduce:

Using LuckPerms: define a specific parent for an user (lp user Player parent set Group), then display his parents (lp user Player parent info), you should be seeing ~> Parent Groups: Group
Then disconnect and log back in through AuthMe ~> Parent Groups: Group world=worldname, Group

(This could be a potential security issue if you want to demote that user later as the statement could be persistent if the permissions plugin only overwrites "global" parent group)

Plugin list:

As the issue has been narrowed down to AuthMe', the following list seems relevant:

Vault, LuckPerms, AuthMeReloaded

Environment description

Spigot / Paper Spigot; SQLITE driver

AuthMe build number:

5.4-SNAPSHOT-b1760

Error Log:

None

Configuration:

Already exposed

Related issues - #1265, LuckPerms/LuckPerms#294

[sgdc3]

@Darlelet could you try last dev build please? ;)

[Darlelet]

@sgdc3 Regarding the (world) context issue this seems to be fixed indeed! 😉

However I noticed two strange behaviors:

• It happens that the temporary parent is not set at all (and user keeps his base group). I didn't manage to reproduce on purpose, but it happened a few times during the testing phase.

• If you connect to server, but don't log in, and then disconnect and reconnect immediately (quickly), it also happens that the user looses his group, and by loosing I mean belongs to neither base group nor registeredPlayerGroup. LuckPerms seems to prevent user from being "groupless" (orphan) so I guess it sets back user to "default" parent group when none is assigned (this seems to be the case here).

I think this misbehavior could also be found in earlier dev builds (considering the minor changes you made to fix #1324).

What do you think?

[sgdc3]

I noticed LuckPerms handles very bad operations on offline players... we should write a proper luckperms integration that directly uses the api, not thru Vault

[sgdc3]

@Darlelet Could you try with the latest dev build? ;)

[DisTrugator]

Latest dev build still have this error on PaperSpigot 1.12.2

[sgdc3]

@DisTrugator Are you using the latest LuckPerms dev build?

[Darlelet]

Sorry for not being the quick-reply guy here 😞, quite busy last few days...

Never mind, just tried out latest Authme build, using LP 3.3.19.

Here's what I noticed:

• This version definitely seems to fix the previous issue causing a player to lose his group.
  I tried a dozen times, didn't happened, the feature is working as expected. 👍
• On the other hand this seems to bring in a new (minor hopefully) bug / conflict with luckperms:
  When LP tries to load specific player's permissions during Authme's authenticating phase, this occurs occasionally:
  
  Here is server's log right before the player gets kicked out ~>

[21:08:07 INFO]: UUID of player XX is xxx
[21:08:07 INFO]: [LuckPerms] [WARN] User xxx - XX doesn't have data pre-loaded. - denying login.

The good thing is that nothing gets lost / buggy tho. Simultaneous operations on the same player simply appear to be unhandled. Who's fault is it to you?

Keep up the good work! 😉

[sgdc3]

@Darlelet This has been fixed by luckperms in the latest dev builds: https://ci.lucko.me/job/LuckPerms/334/

;)

[sgdc3]

@Darlelet Check it out and let us know if that fixed your issue

[Darlelet]

I'm gonna give it a try soon and keep you informed. Should've tried latest LP build aswell indeed, my bad! 😉

…

On Sep 20, 2017, 11:40 PM, at 11:40 PM, "Gabriele C." ***@***.***> wrote: @Darlelet This has been fixed by luckperms in the latest dev builds: https://ci.lucko.me/job/LuckPerms/334/ ;) -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1324 (comment)

[sgdc3]

@Darlelet Any news?

[Darlelet]

@sgdc3 LGTM (15+ attempts or so), good job! 🎉
~ Using latest LP (Build 341)

I guess I should close the issue then? ;p

[sgdc3]

Thank you for the feedback.