How do folks using row-level security (RLS) for authorisation deal with stuff like this?
I mean, let's say Gravatar had only shown profile information to logged-in users. But they didn't want a single user to look at more than 100 profiles per hour. If they were to control access to their API using application code, that's easy.
But if they were to instead delegate that to RLS rules in Postgres, how could they put a per-user rate limit on it?
I generally assume that if info is available publically then it is, you know, public. Of course you do some rate limiting based on IP or similar just to help with DDoS, but if you show something publically then someone will scrape it even if that someone is just a search engine or similar.
Be clear with your user what public actually means but public info is public, there really isn't much of a spectrum there.
Would not that definition make for example a novel use of an API a breach? It is not what the publisher expected, but someone else was creative and used the available data in a new fashion.
I mean, let's say Gravatar had only shown profile information to logged-in users. But they didn't want a single user to look at more than 100 profiles per hour. If they were to control access to their API using application code, that's easy.
But if they were to instead delegate that to RLS rules in Postgres, how could they put a per-user rate limit on it?