Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way for users to submit card contributions #11

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

DogLoverPink
Copy link

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
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.

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.

1 participant