Previously, the permission checks of the /media/:uuid route could be
bypassed for the local filesystem as a media backend, because the
/media/:uuid route performed a redirect to the target after checking
the permissions. Since the target was always /uploads/:uuid.ext where
ext was the extension of the uploaded file, you could simply try to
guess the file extension and have access to the file since the
/uploads endpoint was simply the complete uploads folder mounted.
Now, media uploads from the local filesystem backend are served
under the /media route directly instead of a redirect.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
Docker / build-and-push (backend) (push) Has been cancelled
Docker / build-and-push (frontend) (push) Has been cancelled
E2E Tests / backend-sqlite (push) Has been cancelled
E2E Tests / backend-mariadb (push) Has been cancelled
E2E Tests / backend-postgres (push) Has been cancelled
Lint and check format / Lint files and check formatting (push) Has been cancelled
REUSE Compliance Check / reuse (push) Has been cancelled
Scorecard supply-chain security / Scorecard analysis (push) Has been cancelled
Static Analysis / Njsscan code scanning (push) Has been cancelled
Static Analysis / CodeQL analysis (javascript) (push) Has been cancelled
Run tests & build / Test and build with NodeJS 24 (push) Has been cancelled
The backend end-to-end tests run with many parallel workers that
each start a full NestJS application including database connection
pools, HTTP server and so on. This can easily result in performance
bottlenecks - which is even the reason why we added the --runInBand
option for the CI. The performance can be improved by constraining
the number of workers and memory allocated per worker in our jest
config. Furthermore, we can forcefully close open HTTP connections
in the test cleanup. This terminates connections with a keepalive
flag, that would persist for a while longer otherwise. The following
`this.app.close()` waits for keepalive requests, so this reduces the
wait time.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
This adds rate-limiting using the @fastify/rate-limit module with sane
default values, configuration options, the possibility to disable limits
and differentiation between logged-in users and unauthenticated requests.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
This adds a new endpoint /api/private/csrf/token which serves a CSRF-token that
is stored in the user's session. Following requests with POST, PUT, PATCH or DELETE
request methods, need to provide this token in the CSRF-Token header. Since this
is not possible to do via HTML forms or other cross-site effects, this prevents
cross-site attacks. The frontend loads the CSRF token on app initialization and
stores it in the redux. It keeps using the token for up to one hour and then
updates the stored token from the API endpoint again.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
Fastify is a more modern web framework than express. Although it
shares almost the same API it has a way better performance and
supports more modern features. Several modules like csurf for
CSRF-protection aren't maintained for express anymore but there
is a Fastify replacement.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
As we need to handle datetime in a very specific way,
we need to force strings as the db output.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
As we want to create a new databases for each test, we need to login
as the root / admin user into the DB in the setup.
This extra flag allows us to create a true admin knex instance in the
createTestDatabase method
Signed-off-by: Philip Molares <philip.molares@udo.edu>
As we encountered problems with different databases, it's
easier if we have one implementation that is used around
our codebase.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
We don't need a library that requires as much boilerplate code as
writing the AuthGuard ourselves, especially since the token validation
was already custom code by us.
The previous name PublicAuthToken was a bit misleading, since PublicAuth
could also be interpreted as being used for the public frontend in
contrast to the API. The old name before that (AuthToken) wasn't better
since it wasn't clear what type of auth is meant. I know, this is the
second renaming of the same module in less than a month. However, I
would say the name ApiToken seems rather reasonable and understandable.
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
Thanks to all HedgeDoc team members for the time discussing,
helping with weird Nest issues, providing feedback
and suggestions!
Co-authored-by: Philip Molares <philip.molares@udo.edu>
Signed-off-by: Philip Molares <philip.molares@udo.edu>
Signed-off-by: Erik Michelson <github@erik.michelson.eu>
Erik Michelson
Philip Molares
David Mehren
Yannick Bungers
Tilman Vatteroth