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

Can we protect routes for API endpoints and do rate limiting in Rocket? #679

Closed
raintears opened this issue Jun 27, 2018 · 4 comments
Closed
Labels
question A question (converts to discussion)

Comments

@raintears
Copy link

Hi, I'm using the latest version of Rocket and it's pretty fun to work with. I'm using it to write a restful API service. I followed the guide and added a few routes to test it out just to familiarize myself. I've a few questions because I'm stuck at finding tutorials that walk us through how to protect or secure API endpoints or routes with Rocket.

I'm curious if we can do that in Rocket? Like how do we use a "API key" to authorize a user can access my api routes and how can I implement rate limiting in Rocket?

Last but not least, I was trying to follow the ssl example. I was wondering if it's possible to include the cert and pem in environment variables instead of writing the path in the file itself? will that be safer?

@mettke
Copy link
Contributor

mettke commented Jun 29, 2018

You can find information about SSL with environment variables in the official docs. There is no security difference, 'cause there is no real difference between having information stored in a file or stored in the environment. Both require direct access to the server.
https://rocket.rs/guide/configuration/#configuring-tls

About securing your endpoint, well, I won't walk you through that as it would take too much time. There is no as is default implementation but you can create one yourself by using State with a Database and a Guard for your routes. An incoming request is validated via Guard which does a database request and either lets the request through or not. Rate Limit is pretty much the same, storing information about how many requests were done already.

@raintears
Copy link
Author

Nice, then I'll try the tls example. About the rate limit, do you mean I can use State like a cache to store the request count? How can I store multiple states for different API key? That's possible?

Do you mean using Guard to query database if the API key is valid?

@mettke
Copy link
Contributor

mettke commented Jun 29, 2018

No that's not exactly what I mean.
State is a global Object. Meaning that every thread and every request is getting the same one thus it must be able to access all API-keys and their current usages.

That said, the way you implement that given state is up to you. You can either use a memory database which syncs changes either on change or at an interval to a persistent database or you can use the persistent database directly.

One way to create a memory database (or cached in this case) is using a HashMap. The API-key are used as Map-Key and the Object may contain the rate limit.

The persistent database is pretty much the same. One table for API-keys, another on for requests. You can then count the number of requests over a period of time and see whether the rate limit was reached. You may need to prune that request table as it gets bigger over time.

Those are however only spontaneous ideas and there may be better ways to implement such functionality. I suggest you dig a bit deeper by searching for that very topic on google. You will surely find something, especially outside the rust context. And with a bit of creativity, those ideas can be ported to rust without a problem

@SergioBenitez SergioBenitez added the question A question (converts to discussion) label Jul 2, 2018
@SergioBenitez
Copy link
Member

Looks like we're good here! Note that we've also recently introduced request-local state (#654, #655, #724), which you might find useful when thinking about implementing this kind of functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question (converts to discussion)
Projects
None yet
Development

No branches or pull requests

3 participants