CCCCCCCCCCC tttt
CCC::::::::::C tt:::t
CC:::::::::::::C t::::t
C:::::CCCCCC::::C t::::t
C:::::C CCCCCC oooooooo nnnn nnnnnnn ccccccccccc rrrr rrrrr eeeeeeeee tttttt::::tttttt eeeeeeeee
C:::::C oo::::::::oo n:::n:::::::nn c:::::::::::cr:::rrr:::::r e:::::::::ee t::::::::::::::t e:::::::::ee
C:::::C o::::::::::::on::::::::::::n c::::::::::::cr::::::::::::r e::::eeee::::eet::::::::::::::t e::::eeee::::ee
C:::::C o::::oooo::::onn:::::nnn::::nc:::::ccccc:::crr:::::rrr::::re::::e e::::ettttt::::::ttttt e::::e e::::e
C:::::C o:::o o:::o n:::: ::::nc::::c ccccc r::::r r:::re:::::eeee:::::e t::::t e:::::eeee:::::e
C:::::C o:::o o:::o n:::n n:::nc:::c r::::r e::::eeeeeeeee t::::t e::::eeeeeeeee
C:::::C CCCCCCo:::o o:::o n:::n n:::nc::::c ccccc r::::r e:::::e t::::t ttte:::::e
C:::::CCCCCC::::Co::::oooo::::o n:::n n:::nc:::::ccccc:::c r::::r e::::::e t:::::ttt::t e::::::e
CC:::::::::::::Co::::::::::::o n:::n n:::n c::::::::::::c r::::r e::::::eeeeee tt:::::::::t e::::::eeeeee
CCC::::::::::C oo::::::::oo n:::n n:::n c:::::::::::c r::::r e::::::::::e tt::::::tt e::::::::::e
CCCCCCCCCCC oooooooo nnnnn nnnnn ccccccccccc rrrrrr eeeeeeeeeee ttttttt eeeeeeeeee
Learning project for author to get into the depths of NestJS . The domain model of the application is designed handle vinyl record collection, via REST interface intended to be consumed by a frontend application. For simplicity in hosting (and me learning Security in NestJS and Passport), this application will provide its own authentication.
# development
$ npm run start
# watch mode
$ npm run start:dev
# production mode
$ npm run start:prod
# unit tests
$ npm run test
# e2e tests
$ npm run test:e2e
# test coverage
$ npm run test:cov
The application expects some configuration to be able to run, either from ENV variables or from .env file in root directory.
Example .env file is committed in repository.
ENV variables will override .env file, so .env file can be left in build even if one wants to override its values.
A Swagger server is hosted within the app and can be reached via /api or the json schema via /api-json when running the app.
Authentication mechanism is supported within the application. Users need to obtain a token via basic authentication to be able to use the REST services offered by the application.
Users can also opt in for Second Factor Authentication for increased security. If user enables 2FA and TOTP password from an Authenticator app is needed to gain a token. (More information with flow charts will be provided.)
Succefful authentication with generate two tokens, one jwt token for accessign REST endpoint, and a refresh oken. The refresh token is a one-time-use token that can be used to obtain a new access token if the current ine is expired. See API documentation for more information.
This project is set up to use MongoDb as database. In the _sourcecode- folder data files are provided to populate the database to be able to run the application and should be applied before first start.
The service name; service_mongo_1 should be replaced with the service name of your own container.
# copy file into container
docker cp resources/users.json service_mongo_1:/tmp/users.json
# login to container with bash
docker exec -it service_mongo_1 bash
# run mongoimport (with credentials if needed)
mongoimport -u root -p password --authenticationDatabase admin -d concrete -c users --type=json --file /tmp/users.json
Official backlog can be found in GitHub Projects
Everyone can create new issues in the repository, please add you conceerns or ideas and we will respond to you as sson as we can. Every excepted reported issue will be aaded to the project backlog.
This project is MIT licensed.