You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue defines functionality regarding user accounts for other functions.
It defines the login method, the information required to create an account, the creation of a unique identifier for the account, the method of verifying the account information, etc., and some of them define the technical requirements.
This issue is still in draft. This has not been officially decided and the contents may be modified at any time.
User and Account
A user is identified by an Account. If Account is different, it is considered a different user. This means that one people can create multiple accounts.
Account data
Defines the data the account must have.
ID (Unique. Like Postgres GENERATED ALWAYS AS IDENTITY clause column, defined as PK in most tables)
It will be using bigint type with GENERATED ALWAYS AS IDENTITY constraint.
Account ID (Unique)
This value is a unique distinguished name such as @iamauser. This is a different value from the ID above.
Username
This data is the display name that the user will see on the frontend.
Email Address (Unique)
Email address must be unique. if email is already used, account can't be register.
Password (Optional)
Designate as optional for future 3rd party login.
When saving, it must be saved using a hash function along with salt.
Data for 3rd party login should be managed in a separate table, and it will be implemented in the form of referring to the unique ID of the account through a foreign key.
The data required by the function is defined by each function. Such data must be defined in new tables and linked by foreign keys. Account tables should contain information purely about accounts.
Login
Users can log in with the following information:
Email Address
Password
3rd party login is not considered in the current version. This will be considered later.
Authorization
The definition of 'authentication method', known as session-based authentication or token-based authentication, has not been decided yet. It is technical requirements and will be decide after discussion.
The text was updated successfully, but these errors were encountered:
Summary
This issue defines functionality regarding user accounts for other functions.
It defines the login method, the information required to create an account, the creation of a unique identifier for the account, the method of verifying the account information, etc., and some of them define the technical requirements.
This issue is still in draft. This has not been officially decided and the contents may be modified at any time.
User and Account
A user is identified by an Account. If Account is different, it is considered a different user. This means that one people can create multiple accounts.
Account data
Defines the data the account must have.
GENERATED ALWAYS AS IDENTITY
clause column, defined as PK in most tables)bigint
type withGENERATED ALWAYS AS IDENTITY
constraint.@iamauser
. This is a different value from the ID above.display name
that the user will see on the frontend.Data for 3rd party login should be managed in a separate table, and it will be implemented in the form of referring to the unique ID of the account through a foreign key.
The data required by the function is defined by each function. Such data must be defined in new tables and linked by foreign keys. Account tables should contain information purely about accounts.
Login
Users can log in with the following information:
3rd party login is not considered in the current version. This will be considered later.
Authorization
The definition of 'authentication method', known as session-based authentication or token-based authentication, has not been decided yet. It is technical requirements and will be decide after discussion.
The text was updated successfully, but these errors were encountered: