I may be misconfigured to the point where I can’t get the get_auth_state function to return the scope I need - but I figured out that the spawner.user.orm_user.roles object does inform me that my user has been assigned to the premium_access role.
hub:
extraConfig:
conf: |
async def create_profile_list(spawner):
if any(item.name=='premium_access' for item in spawner.user.orm_user.roles):
profile_list.append( {} )
My question is - what is the problem, if any, with doing it this way?
There’s nothing technically wrong in that it won’t stop working soon. I’d consider the underlying .orm_user object a private implementation detail that will go away eventually, but not likely to change any time soon.
There’s a principle in that roles are meant to only be aliases for collections of scopes and not meaningful in themselves, so checking directly for role membership doesn’t fit with that intention. groups on the other hand, are meant to be associations that admins can use to make decisions. What’s the practical difference between roles and groups? There really isn’t one - both are named objects associated with lists of users.
So if you have a mechanism assigning users to roles, assigning them to groups and checking for the group:
if any(group.name == 'premium_access' for group in spawner.user.groups):
is a fully supported pattern, and practically identical to what you are doing with roles.
No, I meant user.groups. It’s a proxy attribute for the underlying attribute of the orm_user. I’ll see if I can work on the generated docs to handle that better.