Ulysses
Ulysses Stuff => General Chat & Help and Support => Topic started by: Megiddo on August 13, 2009, 11:00:28 PM
-
Howdy y'all! In the spirit of "Striving for Simplicity", I've come to realize that our current UCL implementation is a bit bloated. UCL is what powers our user authentication, and you see it in groups.txt and users.txt.
Things I'm currently planning on changing:
- Sit on top of current garry functions instead of changing them
- Modify garry's auth system to check access when users auth with the steam servers (this is DURING the join process and LONG before spawn), our own auth system will also run at this time. This makes reserved slots react much faster.
- UCL will only support a user being in a single group instead of multiple like it currently does (never used as far I've seen). Access chaining/inheriting will still be supported.
- Remove ability for users to have passwords in order to authenticate (I actually already removed this in SVN a week or so ago and no one's complained yet :) )
- Instead of needing to specify whether the method of authenticating a user is a steamid, ip, or uniqueid, UCL will pick up what you're using automatically. Also UCL will be limited to these three methods of authenticating ONLY, we used to support things like authenticate by name and clan tag, support for those will be dropped.
- Automatically sort access strings alphabetically
- Get rid of 'none' group, add global denies to 'user' group
- I'm considering making inheritance also inherit denies. Since all groups implicitly inherit from the 'user' group, this would take care of adding global denies to the 'user' group (see bullet point above).
- Completely case-insensitive
- Developer-friendly functions to retrieve all current groups and how they're chained, or to see if a user is a group via chaining
- Developers will be able to store their own information in the groups.txt and users.txt files. This is helpful for things like UTeam, which need to tightly integrate with groups, or for UTime if someone wanted to save information for players in plain text.
- Developers will be able to add comments to access strings in ULib.ucl.registerAccess in order to explain what an access string does, I have a few vague plans on how to use this in the future.
- Improve how UCL is handled on the client (most information is not currently updated dynamically). Probably something that will never be used, but nice to have just in case.
The best part is that this new system *should* be compatible with a good 99% percent of current setups with a fairly simple, automatic migratory process. Expect to see work toward this goal in the next couple of weeks. :)
-
- Automatically sort access strings alphabetically
I love you.
Also I'm helping with this. :D
-
Talking to Atomicspark, I'm now thinking about removing the ability to deny things to a group. It just doesn't make sense to trust something to a lower group but not a higher-ranked group. This solves the issue of how to handle denies in inheritance by eliminating the problem altogether :). Denies should and will still exist at the user-level though, in case you have an admin who abuses certain commands.
-
I'm considering making inheritance also inherit denies. Since all groups implicitly inherit from the 'user' group, this would take care of adding global denies to the 'user' group (see bullet point above).
- Shouldn't denies be passed down in the group chain? Like if an admin was denied something operator, and user should be denied it as well?
Going off you note below, you somewhat agree?
Talking to Atomicspark, I'm now thinking about removing the ability to deny things to a group. It just doesn't make sense to trust something to a lower group but not a higher-ranked group. This solves the issue of how to handle denies in inheritance by eliminating the problem altogether :). Denies should and will still exist at the user-level though, in case you have an admin who abuses certain commands.
-
Honestly I think denies in groups is confusing any way you slice it
-
It's like Windows file system permissions. :(
-
Atomicspark, you're not far off in reality. Windows and Linux file systems, and even ipchain firewall rules were discussed in planning of the UCL group/user allow and deny lists.
Modify garry's auth system to check access when users auth with the steam servers (this is DURING the join process and LONG before spawn), our own auth system will also run at this time. This makes reserved slots react much faster.
http://wiki.garrysmod.com/?title=Gamemode.PlayerAuthed - You mean that? Is it that much quicker/easier?
- Instead of needing to specify whether the method of authenticating a user is a steamid, ip, or uniqueid,
Why even IP or Unique?
I'd guess 90% (or more) of all Gmod players / admins use dynamic IP providers; and, though I don't remember fully, doesn't the Unique base part of its system on IP?
Developer-friendly functions to retrieve all current groups and how they're chained, or to see if a user is a group via chaining
ULib Player:HighestGroup() !!!!!
Oh, wait, technically, according to the new 'only one group' stance... that won't be needed even while they inherit other group permissions..
Good!
I'm always for optimization while keeping compatibility when possible.
-
http://wiki.garrysmod.com/?title=Gamemode.PlayerAuthed - You mean that? Is it that much quicker/easier?
It's not easier (not harder either), but it's certainly a lot faster. They'll be authed before they even join the server. :)
Why even IP or Unique?
I'd guess 90% (or more) of all Gmod players / admins use dynamic IP providers; and, though I don't remember fully, doesn't the Unique base part of its system on IP?
It's two lines of code to allow them to use IPs or uniqueids. No waste of effort on my part, and the three different options are all very different from each other, so users aren't going to be able to screw it up easily. I think UniqueID is based off IP when a LAN server and based off SteamID when it's not.
To me, it seems more like a "why not?" feature than anything else.
EDIT: Added "Completely case-insensitive" to the list