3
Schema to restrict the Account prefs field
Source: appwrite/appwrite#1072 · opened by @mlucas-NU
The prefs field in the Accounts API seems like a great feature. It's so common for users to set preferences in applications that it could help Appwrite instances sync a user's preferences across systems or reinstallations. I almost implemented my own preferences as a database collection, but happened to be reading the Accounts docs and saw support for it there.
Should it be possible to enforce a schema on Account prefs?
One downside to letting prefs be open-ended and freely manipulable by any authenticated user is that an attacker could iteratively patch new fields to prefs with big blobs of nonsense data in order to eventually take an Appwrite server down (or cost the host lots of money, depending on the backend).
Should it be possible to enforce a schema on Account prefs?
One downside to letting prefs be open-ended and freely manipulable by any authenticated user is that an attacker could iteratively patch new fields to prefs with big blobs of nonsense data in order to eventually take an Appwrite server down (or cost the host lots of money, depending on the backend).
No pledges yet. Be the first to back this.
Comments
Similar requests
Let's talk about Appwrite's account preferences
4 votes · 0 comments
MCP server for AI-assisted Appwrite introspection
1 vote · 0 comments
🚀 Enhancement: Account creation on OAuth login should be optional
0 votes · 0 comments
🚀 Enhancement: Prevent tampering query by client
0 votes · 0 comments
🚀 Feature: Needed Documnet level security restriction based on its attribute value or relative query which returns true, like in supabase
13 votes · 0 comments
No comments yet.