philippmdoerner / nimstoryfont Goto Github PK

You're about to run into issues with the data-integrity within your database under high load, given that multiple threads are possible.

Imagine this scenario:
You create a new Location. You start writing the SQL for a transaction, which means creating body and title for a searchEntry.
The new location has location X as a parent location, which has Location Y as its own parent.
To create the body, which contains all parent locations, you query data from the table, getting the chain of NewEntry X Y in the searchBody.
Problem is, after you have queried the data, but before you can fire your transaction, another thread changes that location X has parent location Z. So the true chain would be newEntry X Z, yet your searchEntry says something different.

The data modification in between querying the database to prepare the transaction and carrying out the actual transaction can lead to data inconsistencies.
There is 2 ways around this that I know of so far:

1. Find a way to acquire a write-lock on the database before you even start the transaction
2. somehow write SQL statements that do in 1 query all the things you'd normally do in 3 queries, including data manipulation

Campaign Permissions must answer the following questions:

1. Does the user's role allow them the operation they want to do in general
2. The the user's role allow them the operation they want to do for this campaign
3. Is the data they're sending of the campaign they have access for?
   3.1) DELETE -> Get the entry for the ID and check if their campaign_id matches the id of the campaign

Strategy A:
Make it so every API URL must have a campaignName parameter, if access to a given object depends on the campaign.
In the campaignAccess-middleware, you then get the campaign name parameter, you extract the role that the user has for that campaign from the JWT.
You then compare that role with what the user is trying to do. If they're sending a DELETE/PUT/PATCH/POST request and their role for this campaign is guest or lower, deny access. If they try to read and have no role, deny access.

However, this runs the risk of the user creating or patching something in a way that would make it belong to a different campaign.

StrategyB:
You could implement something like the signal system again, but for permissions.
Then connect every model to a permission within their model file.
Change the JWT so it maps campaign-id's to roles instead of campaign names to roles.
Then in the repository you check the permission before you perform the operation, essentially checking if, for the entry's campaign_id the user has a role that has the permission. You'd have to smuggle the JWT data of the request somehow into that thing... however the fuck you want to do that one.

This is to separate general authentication (login) from campaign authentication (has permission to read campaign stuff).

Essentially, in your services have a "convert" function that converts the given data you have into an object that needs to be output for serialization in the end.

Enthus1ast made the suggestion to look into it. It should be fairly easy to write a middleware that can handle this.

This includes:

• Uniqueness constraints (even over multiple columns)
• Cascading deletes
• Not Null constraints on some FK fields (REMEMBER TO UPDATE YOUR MODELS IF YOU ADD NOT NULL CONSTRAINT!)

This will need copious amounts of SQL files. You can do the migration with SQL transactions though:

BEGIN;
CREATE TABLE Customer_new (
    [...],
    CHECK ([...])
);
INSERT INTO Customer_new SELECT * FROM Customer;
DROP TABLE Customer;
ALTER TABLE Customer_new RENAME TO Customer;
COMMIT;

Those endpoints include:
InsertInDiaryEntry
swapOrder
cutInsertEncounter
createEncounter
deleteEncounter
updateEncounter

It's SHA256 combined with pbkdf2.
Throw in a salt and 18000 repetitions and you've got the hash. Now to figure out how to actually build that in nim.
nimcrypto might be a way, though how to get that to do pbkdf2 I don't know.

Enthus1ast made a good suggestion:
When uploading, hash the file body, create a folder based on the hash name and store the file inside of that folder. This way you avoid name collisions without changing the file name.

Once done, remove the old generic article controllers

So far this was done for:
Character
Creature
User

On startup, check various settings in your settings file that you load in.
If the directories specified within do not exist, try to create them.
Do not forget to specify the specific permission, strictly speaking only that server needs access and nobody else.

It might be possible to, instead of passing url params, pass a "DTO", iterate over its fields and extract that data from the request and pass it along to procs.

That way you can deal with arbitrary numbers of parameters and you can just pass a whole proc that takes care of update + serialization. You can even use the genericArticleService inside the actual services to do that, that way it wont be needed within the controllers.

Basically just add an optional "condition" string parameter.

This can then be used when you would else hit the database once per entry, e.g. Maps where serializing their markers leads to hitting the database for the marker's Location once per marker.

All Campaign-related applications should be sub-folder of campaign

All Authentication related applications should be sub-folders of "authentication" (basically: User)

Permissions based on campaign should be also part of the campaign folder

Then you could also get rid of "applications" folder and instead put the "campaign" and "auth" folders on the src-level