Skip to content

Conversation

@DogLoverPink
Copy link
Contributor

This PR intends to address a big issue facing Lorcana-api.com currently where when new sets release, it takes far too long to add all of the new cards to the database. The approach that I think would be best suited to fix this is where trusted community members can make card contributions, while also having safeguards in place in place to combat against bad actors. My current implementation involves having an auxiliary database that mirrors the main database's structure and data, with the addition of a 'submitter-token-hash' column.. When a contributor adds a new card to the database, it is not immediately added to main database, and is instead added to the auxiliary database along with their personal (and hashed) token. Later, a site admin, in the admin dashboard (explained later), can review all contributions, and merge the data into the main database if there's no apparent issues.

The second part of this PR is the backed for the admin part of the site. The admins can add new contributors, check submissions from specific users, delete submissions from specific users, delete users, and merge the contribution from the databases. All of these actions are checked to ensure that a valid admin-level token are sent along with the request.

Although this github is only for the backend of Lorcana-api, I have also taken the time to write a front end for all of the content covered in this PR. I didn't include the files in this commit, as there's not really a good place them, but I can provide them when needed.

Card submission page

image

Admin dashboard

image

Additional considerations for implementation

For this PR to function, 2 more tables would have to be created on the production database. One of them, as aforementioned would be the secondary database, which I called 'card_info_submissions'. The other table would be the user_logins data, which follows this structure:

CREATE TABLE `user_logins` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `token_hash` varchar(255) NOT NULL,
  `permission_level` varchar(45) DEFAULT 'user',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

The last thing to address is concerns related to SQL injection. While all of the code I wrote in PR should be safe from SQL injections, I noticed that previous code written by other people was, well, quite vulnerable. I'm aware that your solution to this was to not give the server write/modify access, however, the code in this PR would require such permissions. This can either be resolved by patching the previously written code, or by perhaps creating another database user that could be used for these purposes.

If you have any questions or concerns, lmk!

@DogLoverPink
Copy link
Contributor Author

DogLoverPink commented Dec 4, 2024

Also, apologies for messy/hard to read code, I went for more of a "get it working" approach instead of a prettier but longer to write approach.

@Dogloverblue
Copy link
Owner

LGTM

@Dogloverblue Dogloverblue merged commit 7f3257d into Dogloverblue:main Mar 3, 2025
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants