Client side options for get_user()

Feature Requests
1

I would like to propose some features around the anvil.users.get_user() function. Or, more broadly, the client accessibility to their user row. Currently, there is no control over this function happily sending the authenticated user row to the client when asked. I think we should provide a couple of different options for the client side behavior.

No Client Side Access

It appears there is already a distinction being made when calling get_users() from server vs client. You could give us an app level flag to disable client side returns of get_user(). This would force users to write their own server function and allow them to handle what data is sent to the client. In this case, if client side calls the get_user() it would raise an exception.

Restricted Scope

get_user() to return only “safe” columns or those that drive good design, ie. don’t verify password on the client side. Then give the option to allow the unrestricted view with a disclaimer of client side access. This may only be available with accelerated tables with q.only_cols().

Unrestricted

The current behavior, return the user row.

Config Panel

Suggested addition to User Management config panel:

get_users() behavior:
No client side access - most secure
Restrict client side access to columns: (Accelerated Tables Only?)

  • email
  • confirmed_email
  • enabled
  • last_login
  • n_password_failures

No client side restriction - least secure (<< current behavior)

4 Likes
2

This would have farther reaching implications, since a client side call to get_user() is what triggers the password reset mechanism.

3

Perhaps in the “disabled” case it could just return bool(get_user()) rather than raising an error?

2 Likes