detleph / server Goto Github PK

There should be a defined folder structure that everone sticks to

The schema should allow for:

• Adding roles to disciplines (with a schema describing the result)
• Storing results in the database
• Differentiation between campaigns and links (links are assigned to a specific group)
• Adding leaders to team (The person who receives join requests)
• Defining an optional description and (maybe) images to
  • Events and
  • Disciplines

Other requirements can and most likely will be added in the future, however, the outlined schema would be a solid baseline for future improvements.

Suggestions welcome

@Stefan-5422 @Flexla54 @michael5031

The traceback is then forwarded to the client, which is, however, expecting a standard error response

How the server responds (falsely) at the following requests:

• GET api/events/"nonexistingPid"
  • 500: Try again later
• GET api/disciplines/"nonexistingPid"
  • 500: Server code
• GET api/role-schemas/"nonexistingPid"
  • 500: Server Code
• GET api/roles/"nonexistingPid"
  • 404: Role not found [OK]
• GET api/organisations/"nonexistingPid"
  • 500: Server Code
• GET api/groups/"nonexistingPid"
  • 500: Try again later
• GET api/teams/"nonexistingPid"
  • 500: Server Code
• GET api/participants/"nonexistingPid"
  • 404: Endpoint not implemented
• GET api/media/"nonexistingPid"
  • 404: Endpoint not implemented

The right response should be from the NotFoundError
The requested "Resource-Name" with PID "nonexistingPID" could not be found!

TODO:

• Select all the relevant routes
• Test all the relevant routes
• Merge into the dev branch

This release should include all the routes in order to predeploy the app (For a simple website without sign up)

There will need to be more custom handlers (Say for 404 pages). Also, it should be made sure that there cannot occure errors inside the error code (which happened today)

Due to merging in weird ways, without double checking what is going on. We have duplicate code, please fix

The server shoud have information for people who (somehow) happen to find the repo

Furhter info: https://dev.to/github/how-to-create-the-perfect-readme-for-your-open-source-project-1k69

As always, this should stay rather PII-free (so no constributors or production link or anything)

Files:

• CONTRIBUTING.md (short and simple)
• README.md (General stuff like installation guidance, description, maybe stack)
  • This should also contain information about Docker and other things that might be a hassle to set up (depending on the machine) -> Especially what email protocols will be used when deploying, ...

The PID is specified after /teams but represents a participant?
Wouldn't /participants/:pid or /teams/:teamPid/participants/:pid make more sense?

Also: please use participants instead of participant (collections are always plural)

Is this already finished and can this be merged?

It is currently not possible to update most of the resources. This is functionality that should be extended (Maybe @Flexla54 for experimenting with express)

Eg. teams that stay unverified for a longer amount of time

Test and if everything is DEFINATELY ok (meaning not unsafe), merge into the dev branch.

I fixed up most of the errors (That would leak information and so on) but there still might be stuff left

@Flexla54 or @Stefan-5422

Controllers may need to include additional checks as simply using requireAuthentication might not be sufficient protection in all cases

Admins can currently update scores to their liking, but there should be some sort of validation (based on the schema prodivded in the RoleSchema)

Using OpenAPI, a usable API documentation should be created for the most important API routes.

The API routes which should be tackled by this task are:

• Events (CRUD)

• Everything relating to user sign up

• Test different strategies for writing the docs

Update

https://www.npmjs.com/package/express-oas-generator seems to fit most of our requirement

Todo:

• Assess ways thorugh which our authentication strategy (bearer) can be included in the docs (possibly even manually)
• Define a standard for restructuring the code so that all code paths in all handlers end in a call to next()
  • Idea: Extend the default .send() functionality in order to also call next()

While testing I saw that some funktions weren't implemented.

Not implemented functions are:

• DELETE Role Schema
• UPDATE Role Schema
• GET Participant
• GET All Participants
• GET Participants with parameter
• UPDATE Participant needs an update (change Teamleader)
• DELETE Admin

Some of these functions are listed only mandatory.

Tick the box, in case a function is obsolete or done!
This references 5696952 (feature-endpoints)

Suggestion: Make this an env variable so it can be controlled on demand and default to like 2 days

Originally posted by @Stefan-5422 in #59 (comment)

The repository's formatting doesn't conform to the format layed out in the .prettierrc file

And merge it into the main branch for deployment

Please make sure that:

• Everything is working as expected (Docker, FS and so on)
• Logging code is turned to production mode (With the NODE_ENV variable)
• #97
• The default admin is removed from app.ts (!!)
• The minimum required features are working (Tho CRUD should be working for all of them except if something went terribly wrong)
• #49
• There is no confidential information in the build (As the whole code could be made public)
• Make sure that everything but reads is currently only available to admins
• Review the authorization code and the media code again (As those are likely the most vulnerable)
• Add CORS

(The prod server should be able to be deployed with this release tomorrow)

Minium feature requirement for the release (C for Create, R for Read, U for Update, D for Delete):

• Auth (C)
• Events (R)
• Disciplines (R)
• RoleSchemas (R)
• Organisation (R)
• Group (R)

every event should store an image, and a markdown file/string for more information about the event

These do not seem to have any effect on the actual product, currently.

There implementation should be eveluated.

Discuss: @Flexla54

It's hard to interpret registrations as failed or real. I'm convinced that

• adding a registration time to the table and
• outsourcing a pending registration to redis (a failed registration, due to eg mail not working, shouldn't be in the postgres db)

would make the life of the registration validators just easier.

I know that it might be a bit late for this, however this site is planned to run for other events too.

After testing and researching some time, I noticed that the current version of the server is quite buggy, especially regarding errors.

For example, the user can currently crash the server simply by sending an ill-formated UUID string. There has also been a case where there was simply no response returned (Which is also sub-optimal)

For these reasons, I think we should focus even more on handling all possible errors and devise tests (with humans at best) to ensure reliable operation (As already discussed during planning)

It might also be a good idea to revise our zero-log policy in a way that we at least store errors that could not be handled (Without any PII so that there aren't as high standards of security to be upheld)

Request for comments: @Stefan-5422 @Flexla54

It currently doesn't load in mail

Events should have a name

We have not set out to use a certain testing environment for this project which one should we use

For use in routes which return different responses depending on the authentication of the user

Currently the server can send emails, but these are just plain text mails. Next up is to implement the mail templates from detleph/email-templates to send out styled emails. After this is complete its time to implement the email verification system.

https://github.com/detleph/api-client/issues/3

Some competitions can have mutliple disciplines with each participant performing another disclipline.

There is currently no way to represent that in the database, which should be chaned.

Currenty there is no admin when the system is first deployed (-> No way to set the server up), so the server administrator has to manually add an admin to the database using SQL.

There should be a possibility to gain default credentials for an admin (maybe through a reandomly generated name, pw or through an env variable)

Add some kind of rate limiting in order to prevent spamming useres with useless emails

Originally posted by @stephan418 in #59 (comment)

In case of problems with the email service of the recipient