Challenge Overview
Mythril API exposes over the network Mythril - a security tool for Ethereum smart contracts, which uses concolic analysis, taint analysis, and control flow checking to detect a variety of security vulnerabilities. In this challenge you will: (i) update API to support rate limits for its users, that will be different for regular and privileged users; (ii) add email integration into API registration flow, and also provide API key recovery functionality via email; (iii) update API unit tests.
Project Background
This challenge is a part of ongoing Topcoder partnership with ConsenSys, a blockchain technology company. For the Mythril team we help with development of the core Mythril tool, corresponding API, website, etc. You should expect many related challenges going forward.
Technology Stack
Mythril API is ExpressJS / NodeJS / JavaScript based. It also relies on MongoDB database and RabbitMQ message broker. API integration tests use Jest and Supertest.
Code Access
The current snapshot of the Mythril API repository is provided in the challenge forum. You will work out of the commit 8509aff2e5312ea8d3a091d0510d15914c8e5cf2 (develop branch). Please, keep in mind that the code is proprietary, thus must not be shared, nor used beyond the purpose of this challenge, according to the standard Topcoder Terms of Use.
API integration tests are located here (a sub-folder of integration-testing branch of mythril-ci repo).
Individual Requirements
All requirements are major:
-
Add support for user account types and API rate limits. Add type field to user account records in the database. For now, we will have two valid types: free and unlimited. Accounts registered via the API registration endpoint should have free type by default. When API endpoints are called, API should track (and store in the database) the number of recent requests done by each user, and enforce the following rate limits:
- For free users:
- at most 10 API calls in the last 5 minutes;
- at most 30 API calls in the last 1 hour;
- at most 100 API calls in the last 24 hours.
- For unlimited users:
- At most 100 000 API calls in the last 5 minutes, 1 hour, and 24 hours.
In case a user hits the rate limits, API should respond with 429 Too Many Requests status, and a human-readable message that informs user about his account type, and the limit he has hit.
The actual API rate limits should be exposed to the api config. -
Provide auxiliary scripts that: (i) update existing user records in the database with added datafields; (ii) upgrade the type of specified user account (specified by e-mail) to the specified type.
-
Integrate API with email delivery functionality, and update API registration logic. When a new account is registered, the user will get an email that contains email verification link (part of that link will be an UUID that expires in 24h). Add to the API a new email verification endpoint, that, when provided with a correct email / UUID pair will generate api key for that user account, write it to db and also return in the API response payload, and also send it via email; otherwise respond with an error. We still allow at most one api key per user account, thus we should check and fail user request, if API key is already generated for that account.
Also add an endpoint that restores a lost API key: provided with a user email, if that email is present in the database, it will re-send API key to that email, otherwise responds with an error.
Although not an obligatory requirement, it is suggested to use nodemailer for the email delivery functionality, with https://ethereal.email/ as test SMTP server. Simple templates of the emails can be hosted inside the codebase.
Configuration of email server should be exposed to the api config. -
Update documentation and unit tests:
- Add information about configuration of email functionality for development and production use into README.md;
- Update Postman and Swagger documentation of the API;
- Update API integration tests for the API. Proper testing of the API rate limits is in the scope, both positive and negative cases (sure, using mock timers).
In case of any doubts, do not hesitate to start discussion in the challenge forum. In case you see that these specifications miss something important for the explained goals of the challenge, please point it out and consider it as a part of the scope.