These secrets can be used to store data from the provider that may or
may not be sensitive.
For example, this will be used by the migration API when connecting to
Firebase to store the service account used for the migration.
This data will only be used internally inside Appwrite and not exposed
to an end user or developer.
These secrets can be used to store data from the provider that may or
may not be sensitive.
For example, this will be used by the migration API when connecting to
Firebase to store the service account used for the migration.
This data will only be used internally inside Appwrite and not exposed
to an end user or developer.
Until we have a clearer picture of why we need it, it would be best to
remove it since it's easier to add it later than to remove it after it's
released.
This allows us to retain the OAuth2 info even if the session is
deleted. This also provides a foundation for allowing multiple emails,
phone numbers, etc, not from an OAuth2 provider.
Until we have a clearer picture of why we need it, it would be best to
remove it since it's easier to add it later than to remove it after it's
released.
This allows us to retain the OAuth2 info even if the session is
deleted. This also provides a foundation for allowing multiple emails,
phone numbers, etc, not from an OAuth2 provider.
A user will have an accessedAt timestamp that will update at most once
per day if they make some API call. This timestamp can then be used
find active users and calculate daily, weekly, and monthly active users.
To ensure consistent updates to the user the $user from the resource
is always updated to the user making the request, including requests
like Create Account, Update Team Membership Status, and Create Phone
Session (confirmation). This ensures the shutdown can update the
accessedAt timestamp if there was a $user set.
Using a database filter is the cleanest approach because it ensures
the logic is applied whenever the user is updated regardless of
whichever endpoint was used.
