Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] API Authorisation and Rate-limiting #2

Open
michaeldera opened this issue May 17, 2020 · 3 comments
Open

[FEATURE] API Authorisation and Rate-limiting #2

michaeldera opened this issue May 17, 2020 · 3 comments
Assignees

Comments

@michaeldera
Copy link
Owner

Is your feature request related to a problem? Please describe.
At the moment the API is public and can be compromised by bots. The API has a limit implemented through the resource it consumed. This can expose the endpoint to a DOS or the API be used for purposes other than what is intended.

Describe the solution you'd like
Each node to connect to REST API must be rate-limited and users must have accounts so that access is controlled.

Describe alternatives you've considered
Giving a secret token to each node meant to use the endpoint to avoid accounts log in.

Additional context
At the moment the API is being consumed by an extension but ideally should be built with the possibility of being used for other purposes.

@michaeldera michaeldera added the enhancement New feature or request label May 17, 2020
@michaeldera michaeldera self-assigned this May 17, 2020
@michaeldera
Copy link
Owner Author

So @nadchif, we are doing signon for mock purposes right now right? Then we use external providers for user management right?

@nadchif
Copy link

nadchif commented May 21, 2020

I think that's the way forward. We use Chrome.identity for Chrome (not yet so sure about Edge)

  1. We use chrome.identity to get the identity on the client side. Chrome identity should give us a token
  2. If the user is not signed in, we post this token to our server's sign in endpoint
  3. Server verifies the above token with Google, and gets the identity of the user,
  4. Server sends back a token (this token will be required in the authorization headers each time the client wants to analyze an image) to the user
  5. Client saves the token and adds it to the headers with each request
  6. Server verifies the authorization headers and leverages them for rate limiting

What do think about this?

@michaeldera
Copy link
Owner Author

So at the moment I think we can leverage Chrome token and after validation we can use the same token as a header.... We can still use the same approach for Edge (I will do further reading to confrim). If not we can structure the JSON to sign in something like this

payload = { token: "TOKEN_GOES_HERE', provider: "PROVIDER_NAME_HERE", }

That way we can extend sign on with multiple providers if we like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants