Replies: 4 comments 1 reply
-
|
I feel this is an actual issue that should be addressed. I can think one one easy protection measurement by adding abuse control to the update prefs endpoint. This is not perfect but a starting point. On top of that, maybe we can add a list of allowed properties and respected rules like the DB has. Would love to hear more ideas. |
Beta Was this translation helpful? Give feedback.
-
|
I feel that we should approach account prefs the same way we handle documents, as those are the only two instances of accepting "unstructured" data. |
Beta Was this translation helpful? Give feedback.
-
|
I love having schemas for things to make my code as type safe as possible. However, for something like account prefs I think that a schema should be optional. One important thing to keep in mind is how easy it should be to change the schema once it's applied. E.g. if I have 1,000 users already, and I want to add a property to the |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, adding a schema means developers will need to migrate prefs whenever the schema is updated. Are there any plans to make Document migration easier when Collection Rules are changed? If so, prefs as a Collection may make more sense than a schema. Even then, complicated preferences that would naturally be stored as heavily-nested JSONs don't seem like they would look good in a collection. |
Beta Was this translation helpful? Give feedback.
-
|
Another option we have discussed in the past, which was in the context of the GraphQL support was to have a key-value object list to represent prefs. This would change the prefs API into a full CRUD.
[
{
"key": "theme",
"value": "dark",
},
{
"key": "language",
"value": "de",
},
]
Not hinting this is a better or worse solution, as the data structure would probably be less ideal for the REST API and better for GraphQL. With this structure we could still have a list of rules similar to what we have today in the database, with the new database refactor we could use a custom collection implementation internally with all the benefits. Devs will be able to add new attributes and delete old ones. Editing an attribute will not be possible in order to avoid re-indexing and table locks for some adapters. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The
prefsfield 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
prefsbe open-ended and freely manipulable by any authenticated user is that an attacker could iteratively patch new fields toprefswith 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).Beta Was this translation helpful? Give feedback.
All reactions