Open michaeldera opened 4 years ago
So @nadchif, we are doing signon for mock purposes right now right? Then we use external providers for user management right?
I think that's the way forward. We use Chrome.identity
for Chrome (not yet so sure about Edge)
chrome.identity
to get the identity on the client side. Chrome identity should give us a tokenWhat do think about this?
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.
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.