Add the concept of authentication methods that authenticate an account
where using the telegram login widget is one such method. If a login is
done with an authentication method that's not associated with any
account the session ends up with the data from the authentication
method in order to allow registering a new account with the
authentication method.
This has to be stored on the session as otherwise it wouldn't be
possible to implement authentication methods such as OAuth2 that takes
the user to a third-party site and then redirects the browser back.
The name is inspired by the watchful owl perching from the tree tops
with complete overview of all that's going on combined with -tide in
the sense it's used for in words like summertide and eastertide.
I firmly believe in free software.
The application I'm making here have capabilities that I've not seen in
any system. It presents itself as an opportunity to collaborate on a
tool that serves the people rather than corporations. Whose incentives
are to help people rather, not make the most money. And whose terms
ensure that these freedoms and incentives cannot be taken back or
subverted.
I license this software under the AGPL.
An account refers to the user the active session is logged in as. As
such it doesn't make sense outside of the /auth API paths that deals
with the current authenticated user. Move /api/account to
/api/auth/account to reflect this.
Replace the convoluted useAccountSession composable with a pinia store
that in addition allows for the consolidation of all session related
functions to grouped into one module.
Provide a basic account system with login and server side session store
identified by a cookie. Upon successful login a signed session cookie
is set by the server with the session stored on the server identifying
which account it is logged in as. The client uses a shared useFetch on
the session endpoint to identify if it's logged in and which account it
is logged in as, and refreshes this when loggin in or out.
