Login methods to accept 'view' objects on the 'users' table

Hello Friends:

This feature request was inspired by this Q&A post.

The request is to enhance the various login methods (e.g., anvil.users.login_with_form()) to accept views on the users DataTable.

This allows applications sharing a users table to select subsets of it rows (a view) that’s suitable for that application, and present only that subset to the login method.

For example, Application-A may only want users with role employee to be able to log in; while Application-B may allow users with role employee or customer to login in. Currently, logic for this must be implemented post login, where a developer must do something like this:

user_row = anvil.users.login_with_form() # User logs in.
if user_row: # Post login.
    if user_row['role'] == 'employee':
       pass   # Allow or Reject.
    elif user_row['role'] == 'customer':
       pass   # Reject or Allow.

If, instead, something like the following were possible, security would be enhanced because it permits the decision to occur pre-login:

1. role = 'customer' # or 'employee' (or whatever the qualifiers).
2. users_view =  app_tables.users.client_readable(role=role)
3. user_row = anvil.users.login_with_form(users_view=users_view)

Here, users not meeting the view qualifier(s) (dimensions) will be unable to log in since they are filtered-out of the view. This happens pre-login (no if/elif conditionals needed). And, if login is permitted, more is already known about the user by code-line 4.

Security is enhanced because the allow/reject decision occurs pre-login; and because less critical code (and possibly accompanying bugs) is necessary; and because you’re confident that the only users accessing an application are the ones you want.

Thank you.

It won’t offer any real security since any user dedicated enough can just replace the line

user_row = anvil.users.login_with_form(users_view=users_view)


user_row = anvil.users.login_with_form()

But yes, it will make your code simpler.

Yes a subset of users can, just like a subset of human can pick house locks.

As well, simpler and smaller code footprint increases the probability of safer code across the skillset spectrum, writ large.


Yes. If this was being done for security purposes, then this would need to be a server-side setting.


Yes, and in that case it could be a backend ability to add an existing users table to Application-B, while at the same time (still on the backend) optionally specifying qualifiers to obtain a subset (a view in the relational sense) needed for that application.

Maybe the secure version of the feature request is to be able to share views between apps in addition to entire tables? That’d have nothing to do with login per-se, but if you shared a view on another app’s users table and configured the Users service to use it (all in IDE settings), then the standard Users service calls would automatically use it.