Are there others that would raise eyebrows that we should know about?
You are right, @p.colbert, anyone can call it, authenticated always get it.
Asking for the status of a background task is another common one. The client has to communicate with the server to get that information.
Without accelerated tables, accessing simple object, media, or linked columns would also use a server call to fetch those.
Search results are paged, so iterating through those on the client will make a call to the server every so often to fetch new pages.
Those are the big ones, I think. Mostly it’s just important to know about them for efficiency purposes.
1 Like
Emphasis on “can have rows returned to the client from the server”. The potential vulnerability here is that for a Users table which is not client-readable there does not even need to be any server code returning results from this table. In a sense you could say there is such server code, but it’s already built into Anvil. It probably should be pointed out in the docs that client code can read all columns of the Users table for the current user even when you’ve written no server function to do that, because this behaviour is different from all other non-client-readable tables.
I’ve made a feature request here that I would love everyone’s input and collaboration on:
yikes - didn’t realize the row ids can change. I’ll be using uuids from now on.
1 Like
Hi all,
Apologies for being late to this thread; I’m on the road atm. Dropping in to clarify a couple of things:
1. Row IDs do not change!
I want to say this again: Row IDs are stable. That is the entire point of unique row IDs.
I think @pcolbert above might be getting confused with the clone process: When you clone a database (including by cloning an app, or migrating to Extra Server Resources), the new rows have new IDs, because they’re new rows in a new table. But the existing rows keep the same IDs until and unless they are deleted!
This does mean that if you are referring to a row from some record outside Anvil, it’s useful to use or create an alternative identifier. That way, if you clone your database (eg to create a staging version of your app to debug some issue), you can maintain those links.
2. Sensitive information in Users rows
It is true that, because any session can call anvil.users.get_user(), the contents of the row in the Users table corresponding to the currently logged-in user can be read from the client.
It is also generally true that links can be followed, including by user code - if you return a row with a link in it to the client, then the client code can follow that link and read the target row.
However, this can create sharp corners, of the sort that prompted this thread, and we’ve been working on putting some safety caps on them. This thread has slightly pre-empted some work that’s on its way, so I’ll break our usual rule and talk about an unreleased feature:
Upcoming functionality below:
We’re going to allow you to mark columns of tables as “hidden from client code”. This means that, while server code is able to access those columns, client code cannot. In @racersmith’s example, this would allow you to hide the link_to_other_table column from untrusted access, but keep the naive table layout. (When you pass that table row to server code, it will be able to see the sensitive column.)
This is coming Real Soon Now™, so if you can bear to hold your horses for a little longer, I’d encourage you not to go rewriting all your apps!
14 Likes
Thanks for the correction, @meredydd ! I think I was remembering a Forum discussion between us from years and years ago, but that’s moot now. I will immediately go back and correct my posting above.
Edit: Corrected. Apologies to all for the outdated information.
1 Like
Real Soon Now™?
Phew, crisis averted!
@meredydd: Thank you for this announcement, which is a relief! The row ID issue irritated me and I was just about to change my DB structure. Nevertheless I will add UUIDs and think about further security addons. Looking forward patiently to these new features. Thanks!