WebSentry currently using mgo which is a community mongoDB driver and it is unmaintained.
We should switch to the mongo-go-driver which is a official mongoDB driver and it's currently in the final beta.

The current slave part is more like a proof of concept with pretty bad code quality. Since there aren't that much code, maybe just refactor it.

Things should consider:

• use typescript (or at least add eslint)
• use async/ await keyword
• allow jobs to run in parallels

WebSentry

• Logo
• Server side i18n&l10n
• Handle extreme long pages
• Security improvement (limit request rate)
• Improve code quality
• Doc
• Statistic

Notification

• Mail support
• Telegram support

WebSentry-Frontend

• First working version

WebSentry-Slave

Move:

1. Token => HTTP header
2. Sensitive data => post-form
3. Other data => parameter

After some internal discussions, we decided to settle with PostgreSQL (and maybe sqlite for a lightweight self-host version).
This will introduce a lot of incompatible changes and we will stop rolling out to dev environment for now.

Task:

• Replace MongoDB driver/model with PostgreSQL(gorm). #39
• Support transactions properly. #40 #41 #42
• Update front-end to fit the API changes. websentry/WebSentry-FrontEnd#46
• Testing.

• i18n
  • backend
  • frontend
• Settings: language && time zone
  • backend @CaviarChen #54
  • frontend @MarsXue @zijies1 websentry/WebSentry-FrontEnd#52 websentry/WebSentry-FrontEnd#53 websentry/WebSentry-FrontEnd#54
• Settings: change pwd && reset pwd
  • backend
  • frontend
• Pause \ Disable sentry
  • backend #55
  • frontend websentry/WebSentry-FrontEnd#58
• Quota: Sentry number limit. Auto pause after a while.
  • backend
  • frontend
• Captcha on critical api.
  • backend
  • frontend
• Delete notification.
  • backend
  • frontend
• Edit Notification / Sentry
  • backend #55
  • frontend
• Add new email notification
  • backend
  • frontend
• Frontend Create Sentry Refactor
  • frontend
• Handle corner case (backend)
  • target website down
• Error handling (Frontend)

In order to prevent things like brute force attack, we need a better rate limiter.

Overall, the task has two steps:

• add a standard rate limiter.
• add CAPTCHA to protect sensitive api.

For the first step, the design is:
Api will be grouped into different sections and each section has it's own limit key and rate value, such as:

• sensitive (login, register etc): key: IP, limit: 500 req/h
• general api: key: user id, limit: 1000 req/h
• request full screenshot: key: user id, limit: 20 req/h
• slave api: key: ip, limit: 5000 req/h

The POC version seems working well, we should start working on MVP.

• rename repo
• rename stuff in the worker repo websentry/WebSentry-Worker#11
• rename stuff in the main repo #47