26 db migration, type safety, domain layer and insert project api #32
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Does this need to be rebased or does it actually have 102 commits? |
.env.example
Outdated
| @@ -1,6 +1,7 @@ | |||
| POSTGRES_HOST=db | |||
There was a problem hiding this comment.
Why change this? Would need to be db on the docker network, no?
There was a problem hiding this comment.
check, changed back.
Removes all derived data Models all relations/links in a similar way Refactor relations a bit further
Add optional license file path to app metadata Add default for license_file
in order to make the domain model not be special for the dependencies of the project
francisduvivier
force-pushed
the
26-improve-type-safety-for-db-queries
branch
from
538c13f to
59ce14f
Compare
|
Note:
|
| const name = projectSlugs[id]!; | ||
| const slug = name.toLowerCase(); | ||
| const description = getDescription(name); | ||
| const userId = random(userCount); |
Check failure
Code scanning / CodeQL
Insecure randomness High
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix AI 25 days ago
To fix the problem, we need to replace the use of Math.random() with a cryptographically secure random number generator. In Node.js, we can use the crypto.randomBytes function to generate secure random bytes and convert them to a number. This ensures that the generated random values are not predictable.
We will:
- Import the
cryptomodule from Node.js. - Replace the
randomfunction implementation to usecrypto.randomBytesto generate secure random numbers.
| @@ -2,2 +2,3 @@ | ||
| import express, { Express, Router } from "express"; | ||
| import { randomBytes } from "crypto"; | ||
| import { | ||
| @@ -78,3 +79,5 @@ | ||
| function random(n: number) { | ||
| return Math.floor(Math.random() * n); | ||
| const randomBuffer = randomBytes(4); | ||
| const randomNumber = randomBuffer.readUInt32BE(0); | ||
| return randomNumber % n; | ||
| } |
Upload API PR
This PR is preparation for enabling app uploads on badgehub. For enabling this, a lot of stuff was changed as described below. A lot of stuff still has to be done as well, but this PR is feature par with what we currently have.
Related PR
badgeteam/badgehub-frontend#16
Done
db-migrate
installed db-migrate and added the new table structure as a migration
sql-tagged-template
all sql code is now using sql-tagged-templates which helps with readability, README.md was also updated for this
Insert Project
You can now insert a project, which will also create an empty version and metadata and this project can then be retrieved
Publish project
The publish patch api on a project will mark the latest version as published now
Write API only enabled in development mode
Since we don't have security on our api yet, I added code that makes sure that the upload api only works when the NODE_ENV is set to development
Auto run db-migrate:up on start
Also added project_statuses_on_badges table and dependencies table
Migrate sample data
README.md was updated with instructions
Tested with frontend for feature parity compared to master
Kept changes to fronted minimal by keeping current http api almost the same
TODO
Consistent naming:
Make a full app upload and download api MVP that the badge can use
Single File upload
You should be able to upload a file and this file should be put in the db and stored on disk using it's hash as the filename, like git does it, so also with 2-letter subdirs ideally.
if the file path is /metadata.json, then data should be extracted and filled in on the app_metadata_jsons table
Single File download
Zip upload
When you upload a zip, file upload should be done for all the files in the zip (so also extracting metadata)
Q: should zip upload also do publish?
A: no, it should not, there is an api for that. optionally, we can make it a query param later
Zip download
(one/many) to many relations from the relations dir
Maybe change http status codes and message
Maybe improve SQL debugging
Change it to make it clear that draft version is always unpublished
=> so publish should also create a new version
Maybe add more documention regarding the philosophy of the database structure, the file management, the git/metadata.json as source of truth and the port and adapter stuff.