feat: allow per-user settings and store them in database

[Monirzadeh]

First step for real separate user in Shiori.
The goal is to move each user settings to the database and call each setting separately for each user.
I'm done some part of code but not push yet (it is not clean). It will be completed step by step until be ready for merge.

Why we need this?

• I explain some part of reason in this comment Allow for a custom css configuration file for the reader mode #338 (comment).
• Maybe we can use this feature for cleaner code for Allow for a custom css configuration file for the reader mode #338 and make it per user
• in the long term, maybe we can separate bookmark databases for each user. (we should keep public bookmark feature)

TODO:

• add needed field to the database
• update model
• update database.go to get database account information
• update function for call data from database (sqlite)
• settings of each user based on data called from database for that user
• change logic to save configure just as on text field in SQLite
• API for update setting record in database (better name for endpoint)
• save settings from UI (do i need loading indicator while save in database?)
• reflect updated value to the session
• mechanism for check if configures is a valid json before add to database.
• update function for call data from database (mysql)
• update function for call data from database (pg)
• add function saveSettings for other database.
  • MySQL
  • PostgreSQL
• SaveAccount to SaveAccountSettings and configures to config
• mechanism to migrate from old database to newer version and not break current instant of Shiori with data.
• use json instead of text for config in database
• Visitor account can't save settings because some settings not available for them. and validsetion check owner status fix that
• can we use json or text for all database? Done all of them the same way in all database is better solution if it is possible
• move update config in account variable to a function for more readable code
• Done remaining TODO in code
• down migrate script
• fix some typo and update createEbook
• Remove unneeded part because of driver.valuer
• remove default config value for new user.
• merge with master and solve conflicts
• move to new API
• solve validationsession
• remove jsonify
• unit test for database
• unit test for API

Repeat for other database

What I need to know?

• Specific security concern or test that should be pass?
• Any specific settings should be active for new user by default?
• Should I change current API for update settings or create new one?

Things make work unnecessary harder

• current first user logic
• first user (shiori with gopher) have problem before save that in database if user save new settings. Kinda bug in current logic be sure it solved. after version 1.6 it not a problem anymore.

Should be checked before merge:

• does it work on SQLite?
• does it work on MySQL?
• does it work on PostgreSQL?
• can migrate database without any problem?
• any specific security concern?

[fmartingr]

Hey @Monirzadeh, thanks for looking into this! One side note though: Keep in mind that I will need to take over all API/DB modifications over to #497, so the more concise they are the better.

I will try to merge the partial effort ASAP so we can iterate further in that direction, but the fact that the two APIs have to coexist for a little bit will make things difficult. I will gladly listen to some feedback on that end.

[Monirzadeh]

Hi @fmartingr
I change configure on database as you want (for SQLite for now). Generate shiori-settings from database too (try not to change current settings logic).
Please overview the code and confirm if it hasn't a critical problem in the logic. (it is not removed all old changes yet)
Update: please review to-do list notes. specialy

(can we use json or text for all database? Done all of them the someway in all database if it is possible)

One question remain on my side:

• Should I write a complete new API for update settings, or I should change the current API for that? Please answer this part, so I can go forward
  for now, we have a new API in last commit (not completed yet and need a better endpoint name)

Side note:

• first user is horrible in shiori (it is not present in database until you create that after login) can we change this part of code? (it makes code unnecessary complicated). For example, if I try to update user settings for shiori before really create that in database (first login), GetAccount return empty result. (I work on some part of API but not push that it is not complete yet)

[fmartingr]

Left some comments

[Monirzadeh]

I don't touch shiori-token but it not removes on logout from browser, is it normal?

[fmartingr]

I don't touch shiori-token but it not removes on logout from browser, is it normal?

You need to remove it (empty the shiori-token local storage key or remove the key altogether) on logout.

[fmartingr]

Amazing work @Monirzadeh ! I have left you some small comments but this seems good to go.

I'm going to hold this on until 1.6.1 first or until I check in which state we can ship 1.6.0 as per the roadmap.

Remember to update the branch from latest master too

[fmartingr]

Awesome, this is ready to go :)

[fmartingr]

Hey @Monirzadeh let's fix the conflicts here and merge this directly for 1.6.0.

[Monirzadeh]

@fmartingr it is ready