So basically, I think the 3-way system is a good start. We have a general API (the auth API), that both auth providers and auth consumer use. So for each part, the goals are probably sightly different:
Auth Provider API:
Goals/ideas:
- support for multiple auth providers at once
- support complex auth providers as well as simple ones (group/flag/permission based auth should be supported)
- support for different auth methods (steamid, name, ip, passwords etc.)
Implementation
1. Multiple auth support:
Probably a listener-style way of adding auth could work well. So, when the Cusomer API function X is called, it is validated against all authproviders - I suppose it makes sense that the user is "authenticated" if one of the providers return True for the checked permission.
2. Supporting complex auth methods:
One approach to solve this problem is to provide general functions - as the actual permissions/flags/groups are going to differ on each authprovider, the providers could just check for each permission internally; so if we have a simple auth provider that only checks for ID, it will return True in any case, however, with a more complex provider it checks against any flag.
Something else to think about is whether it makes sense to provide default-API flags; Sourcemod for example has a pretty complex system regarding the flags and so on - if some scripters intend it to be more specifically for sm, they'll use that group and other scripts may have similar groups but with a different name (so they won't get recognized). A solution could be to provide a bunch of predefined flags /groups/permissions that custom providers can just override if they have a similar function; however, this may lead that the API becomes quite large (and possibly 'bloated') and that it has some 'features' that are barly used by any auth provider.
3. Support for multiple auth methods:
I think a decent approch here is too loop though all registered auth methods for each auth provider until one returns True. If they are not implemented, they just return False with no extra work.
For custom auth methods that are not used in the default, there could be a method to add them to the internal list.
On the Consumer API side everything should require as little work as possible - possibly all that is done is giving a userid (and then these checks will be automatically done - including the retrieval)
Auth Consumer API:
Goals/ideas:
- simple to use (single function)
- access to complex auth mechanisms
1. simpilcity
Access could be done though a user specific class that just uses the userid parameter for the constructor and specific methods for checking access. For example, it could be something like Auth(userid).IsAuthed()
2. access to complex methods
Using the approch above it could be rather simple; for example it could be something like Auth(userid).InGroup('admin') and Auth(userid).HasPessmission('be_awesome')
Looking forward to comments & ideas. I would be up for writing this API :)
(Note: Also see http://www.sourcepython.com/forums/showthread.php?13-Admin-System )
Alpha/Prototype auth API + Simple Auth Provider + Test Script
auth/__init__.py
auth/consumer.py
auth/provider.py
Simple Auth Provider
Test Script
EDIT: Of course you have the permission to include any of this in SP under the GPL