User blacklist for preventing re-registration about matters-server HOT 9 CLOSED

After looking at current IP record, it looks like IP sharing is very common for our user. Therefore we can only rely on canvas fingerprint. Banned state can still be inherited between email and canvas fingerprint.

We will also need to integrate reCAPTCHA (or any other method for verifying human). As reCAPTCHA v3 returns a score, we will need to integrate it first to acquire score distribution before starting to use it.

from matters-server.

(5) [client] ban user

from matters-server.

(5) [server] ban user

from matters-server.

reCAPCTHA integration

from matters-server.

Backend flow:

Please let me know if I'm wrong or asynced. 🙏🏻
@guoliu @robertu7

from matters-server.

Banned users may not try to log in if their token is still valid.

As I mentioned before, Would it be simpler if we add this logic in withApollo.ts since we already have some custom headers like x-client-name and x-sentry-action-id?

We will send this custom header to the server through API requests, no matter what user state they are, but let the server to determine if accept it.

from matters-server.

I agree with @robertu7 that we should get canvas id in withApollo.ts, and send it as header. I think the flow @devformatters drew here is for backend only, and user logon means any request to the server. If so everyone should be on the same page 😁

For the "banned user logon" flow, we also want to record multiple records if the user logon with different canvas id. And for the "new user registration" flow, we should also check on blacklisted email, and record canvas id if matched.

The rest looks good to me!

from matters-server.

@robertu7 @guoliu
The points you guys made are correct, x-user-agent-hash always comes from header that I didn't describe in flow chart. (my bad 🗿)

For the "banned user logon" flow, we also want to record multiple records if the user logon with different canvas id

The flow should resolve it because system will record once banned user send any request with canvas id not existing in our table.

And for the "new user registration" flow, we should also check on blacklisted email, and record canvas id if matched.

It makes sense. 👌🏻

from matters-server.

Close it since we've shipped. Feel free to create a new issue or reopen.

from matters-server.