[BACKEND] A platform for companies to advertise their job opportunities to students
License: GNU General Public License v3.0
A platform for companies to advertise their job opportunities to the students.
API Documentation is available for the main branch and for dev as well.
Made with ❤️ by NIAEFEUP.
To start developing, please check the documentation on how to configure your local development.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
In the /register route, if the user is not succesfully created, the response will be:
Lines 68 to 72 in 86739e1
The specified reason is not always true since the error can be caused by other reasons: bcrypt fails to generate salt or hash the pw, db connection issues, etc.
Its also important to distinguish a bad request (400) from server errors (500).
A possible solution is to use error types or codes. For example, Mongo provices an error code for duplicate entries (11000), so something like this can work:
if (error.code === 11000) {
return res.status(400).json({
"success": false,
"reason": "Duplicated username",
"error_code": ERROR_TYPES.DB_ERROR,
});
}
return res.sendStatus(500);I'd also suggest to drop the JSON notation on res.json since it accepts JS objects and makes the code more readable.
As discussed in #47, we should monitor the API usage once this goes online, so we can figure out if the api rate limit (currently 100 req per 15 minutes, per user - about 0.11 TPS) is enough for general usage.
For this, it is important to check the logs and look for HTTP 429 responses.
Create a comprehensive readme that states how to start the development server, as well as how to run tests and configure docker
Although this project already uses Docker, which basically eliminates issues that arrise from using different environments, there are still some issues that cause errors on Windows.
The TLDR is that npm test and pushing to git don't work on Windows.
The test script doesn't work in Windows due to the way env vars are set, plus the way two consecutive commands are executed in cmd. The best solution that I'm aware of is to use the cross-env package. The issue with pushing to git is due to the pre-push hook that calls that same npm script.
(I was previously able to edit the code and run the tests by manually editing the npm script)
Endpoints to add:
The login endpoint should receive the following fields:
The register endpoint should receive the following fields (the one time token is not yet in use):
The apply for our site endpoint should receive the following fields:
In order to complete #6, companies need to be able to provide their contact information when applying to nijobs.
Discussions were already started regarding the validation and structure of the field here: #51
Additionally, in order to complete their profile, they need a bio and a logo. This endpoint should receive those 3 and complete the Company instance that was created when approving the application.
In order to make this process easier on the frontend, I'd suggest adding a boolean field to the Company meaning that it has completed the registration. We would use that field to show the "Complete registration widget" but also to prevent companies from creating offers before completing the registration (purely backend limitation, since the frontend won't show the button before the company is fully registered)
NIAEFEUP/Website-NIAEFEUP#199 is a good starting point on the logo storing feature.
Hide applications (useful for avoiding spam)- does not delete, but marks them as hidden so that they can't submit another application multiple times with the same email
Create a boolean field that sets CompanyApplications hidden.
On the company application search, only return non-hidden applications by default, and add a query param to make also the hidden applications visible.
As per the documents in the drive.
Should add Log(s) that are associated with Companies and store their actions (such as Adding, Updating or Deleting Ads) - see the documentation produced in the meetings.
In order to have a common and easy way of listing requirements on offers, we should have a requirements field that is separated from the description, and lists the requirements.
To simplify, it can be a simple String array, where each entry is a requirement.
Later on, we can have smarter requirements, as a Map with specific keys, to be able to have experience restrictions, knowledge in specific areas, etc...
I think it might be insteresting to add a semple env file in the repo's root (e.g. .env.example) instead of explaining how to setup the env file in the README.
We could even add a .env file and setup dotenv-flow to allow overriding the env file with a local version (e.g. .env.local).
This change would allow the README setup instructions to become simpler aswell: just run cp .env .env.local and fill in the variables.
If this is done, we should also add a .env*.local entry to the .gitignore.
A company cannot have an offer published more than 6 months (currently)
This validation is only done in the Model level. When it fails, the error is thrown but it is an UnknownError since they are masked before outputting. We should have a validator on the route level so that it throws a comprehensive error
For example, we mention in the README we are using Mocha and Chai, but we have since moved to using Jest.
According to LGTM analysis, we are performing database accesses without limiting the API calls. After some research, I found that the most used (and it seems to be an alive project, so it is updated) is express-rate-limit (https://www.npmjs.com/package/express-rate-limit).
The alternatives to store the access cache are the node process internal memory, redis, memcached and mongo.
As we might deploy the server in a cluster in the future, across multiple node processes in parallel, it's important to store the accesses in an external cache. redis and memcached are optimized for reading, and it seems the implementation is quite easy, so I recommend using the redis approach, by adding this package as well: https://www.npmjs.com/package/rate-limit-redis.
Additionally, after looking at the express recommendations for security (https://expressjs.com/en/advanced/best-practice-security.html), we should adopt some of them (some are already in place, yay) such as the helmet plugin (https://expressjs.com/en/advanced/best-practice-security.html#use-helmet)
Express is a decent library/framework (who cares, really?), but it does not enforce any structure at all, which can result in getting stuff all over the place.
So, we should follow something like this - I'm reading it now and it all makes a lot of sense. We can iterate on it, but I feel that at least a basic level of what's described there should be implemented 😄
See #20 (comment)
TL;DR: Should we have indexes in the DB? I'm feeling that this should be a yes, but the complex searching by several fields makes this not very clear.
I think it would be interesting to add package auditing to the continuous integration to avoid (at least to filter high vulnerabilities) to keep our packages clean-ish.
After building the images/containers, the tests can be ran with:
docker-compose up test mongo --exit-code-from test
Running this command raises an error (ERROR: No such service: --exit-code-from), since the flag should be specified before listing the services (this way --exit-code-from is being treated as a service).
The command should be updated to:
docker-compose up --exit-code-from test test mongo
Steal from NIAEFEUP/nijobs-fe#22 😁 (except the React configurations, obviously!)
A Company Account should be able to edit its Company's details.
I now believe that Jest tests are much cleaner. Plus, Jest can run tests in parallel for better performance and has mocking built-in, as well as coverage reports!
When dealing with information that will be shared in backend and frontend such as the Offer field values and technologies for example it is helpful to have it in a single place to avoid inconsistent data.
Another use case are constants that are also used in the frontend for client-side validation and error messages that are also parsed in the frontend to show a human readable message.
In order to support Company and Admin accounts, the Account schema should be updated to contain the following fields:
emailpasswordisAdmin : Booleancompany : Ref to Company ModelAdditionally, if the Account is admin (isAdmin === true), company must be null. If company is non-null, isAdmin must be false.
Furthermore, the following middlewares must be created:
isAdmin - the logged in user is an adminbelongsToCompany(companyId) - the logged in user is a representative of the companyThere should be a way to archive offers. It would work similarly to the way the hide functionality works, but it has a different semantic meaning.
isArchived defaulting to false on Offer schemaSearch Fields:
Add restrictions to a Company, so that it cannot have more than X Offers active at a certain time when creating an Offer.
Currently, the /auth/me endpoint is only tested with an admin account.
Create another test where a company representative account is used and the correct information is retrieved. Also, test the case if for some reason the company linked to it does not exist (it should not return, but the request should succeed with the rest of the information)
Relevant information:
The node versions we are using in the Dockerfiles seem to be LTS 8. However, the current LTS is 12.14.1.
We should update the app to this LTS, alongside the dockerfiles and any other configurations that need changing.
This is quite pressing as the version mismatch is pretty high.
Modelar uma base de dados que represente o MVP.
A Company Account should be able to edit its Company's Offers.
Add filters to offer getting (searching).
We are hardcoding the status codes everywhere. We should have an enum for that.
Instead of creating an enum manually and risk forgetting some code, we can use a package like (https://www.npmjs.com/package/http-status-codes) - it has no dependencies, as it is basically just an object with all the codes. Not much else needed tbh.
It would make the code cleaner, and semantics wise it's actually better for those who don't know their http codes by heart.
DO NOT FORGET TO UPDATE THE TESTS AS WELL
The Company representatives should be able to create Offers, so the permissions should be migrated from Admins/admin_token.
approvalDate + submitDate + rejectDate (the dates - except approval - are null until changed to represent that that event did not yet happen)When setting up CORS headers, all origins are being allowed to call this API, which is not ideal in a production environment. (src/loaders/express.js)
Instead, the Access-Control-Allow-Origin header should read the value from an env file, so that we could have only our trusted sources call our API, such as the application Frontend (http://github.com/NIAEFEUP/nijobs-fe/).
Surely, in the development env file, the allowed origins can still be * for an easier development
As per the documents in the drive.
Should add Reports(s) that are associated with Ads, created by the application users.
Some types are mentioned in the documentation:
But others may be added.
The type must be required and it might be a string with the enum values mentioned above, plus "Other". If "Other" is specified in the type, then an explicitType field is required (suggestion: use a custom required function).
When using the API naively, I did not know the contacts format so just assumed an array of strings. It did not give me a validation error, as it should.
After this, I started thinking about what should be the format. First, a single string could be enough, but that's not very informative, and the company might have more than a point of contact.
So I think it's best to have a Map(String, String) to match a name/person to an email/phone number so that it is more informative on who the candidate will be talking to. Maybe there will be cases where the email is generic and no specific person will be linked.. Simple: use map(email, person) where the second can be an empty string
(This is probably not the ideal way to do this, but it is a good compromise in order to get things rolling quickly)
Requires #52
When loading the connection to the mongo service, we should check if an Admin account already exists. If not, we should create it based on environment values (ADMIN_EMAIL and ADMIN_PASSWORD).
When passing a past end date, and no publish date, it takes the default publish date which is now, however, since end date is in the past, it crashes without failing the validation. It should check the endDate vs publishDate on validation.
Another approach would be to prevent the creation of offers with an end date in the past.
Just to clarify, the model has a jobStartDate, and jobDuration, that refer to the job itself, however publish date and end date refer to the job posting, maybe we should change the endDate naming to make it clearer (maybe publishEndDate?)
Relevant information:
When running the tests, due to jest running everything in parallel, there is a lot of console logging that is repeated (loaders initalization) and endpoint hitting (morgan messages).
When it test mod (NODE_ENV=test) these should probably be disabled as they make debugging and understanding the test output harder.
Mostly explained here: #20 (comment)
Needs changes to the TravisCI configs. Maybe also a good time to investigate other CI options, such as CircleCI (it's looking pretty competitive and the ease of specifying several jobs might be helpful, considering #18 too).
Create an endpoint to return the information about a specific Offer.
Something like GET /offers/:offer-id will do.
It should return:
As per the discussion in #31, removing hooks will probably be beneficial.
This should be as simple as removing the package and the associated entries in package.json.
Currently, due to the reverse proxy setup done with niployments, express cannot correctly parse the requester, and cannot deal with the secure cookies (check NIAEFEUP/niployments#24 and expressjs/session#281).
From the express-session docs:
proxy
Trust the reverse proxy when setting secure cookies (via the "X-Forwarded-Proto" header).
The default value is undefined.
- true The "X-Forwarded-Proto" header will be used.
- false All headers are ignored and the connection is considered secure only if there is a direct TLS/SSL connection.
- undefined Uses the "trust proxy" setting from express
This will prompt express to look into the "X-Forwarded-Proto" header (added in #NIAEFEUP/niployments/pull/24) and make the secure cookies (and thus authentication) work in prod 😎
nvm or asdf). This information should be added to README as versioning tools suggestions.Conceptualize a way to stop companies from spamming posts and implement it.
In the /register route, both username and password lack proper validation. A string consisting of spaces will be valid and saved in the database.
A possible solution is to use trim() and then length. A more robust (but more complex) solution is to use something like @hapi/joi.
Mongoose models can also have required and validate fields.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.