#fobor10362 - rate limits

1 messages · Page 1 of 1 (latest)

thorn geyser
#

It's a per second rate limit

#

So any requests beyond the per second request limit would get rejected

#

Are you seeing rate limits?

#

Also how would one customer cause > 100 stripe requests per second?

sullen bane
#

Ok. No I am just trying to figure out how I could protect myself

thorn geyser
sullen bane
#

I saw that link

#

So if you have 100 customers at the same time make a payment, you get rate limited?

thorn geyser
#

If 100 customers were on session at once, it likely wouldn't cause rate limiting. 100 requests would have to be made exactly in a 1 second time interval for rate limiting to start occurring

sullen bane
#

I mean, it is possible. It doesn't have to be just making payments it could be from other portions of my site like cancels.

#

I am wondering if it does happen though, how long will it last?

#

What about refreshing the page for instance, where I only allow people to cancel if they have an outstanding balance of $0 and if they do not have a certain active product id subscription

#

It checks the API for that information in ordeer to access the cancel page.

#

Maybe for that, I should use redis caching to time people out from making too many requests?

thorn geyser
#

You should utilize webhooks and store as much data as possible in your database

#

To reduce load on stripe api

#

also get requests are separate rate limits than post requests

#

That is outlined at the rate limiting docs page

#

You can have up to 200 req/sec (100 reads and 100 writes)

#

That is a large amount

sullen bane
#

right ok

sullen bane
#

Can you look for me how long the rate limit lasts for?

#

I have my code for the cancels too if you want to advise me on it

fallow goblet
#

Hello! Taking over and catching up...

sullen bane
#

ok np

fallow goblet
#

Not sure what you mean by "how long the rate limit lasts for", but I will say that Stripe has very generous rate limits with burst capacity and we have very large merchants who never come close to hitting them. I highly doubt it's something you need to worry about.

sullen bane
#

in other words, how long will it take for customers to be able to use my site again (stripe functions) after being rate limited?>

#

1 hour, 1 day, something else?

fallow goblet
#

That's not how our rate limits work. We limit on a per-request basis. For example, if you exceed our rate limits by one request, you'll get one 429 response for the one rate limited request. If all of your other requests remain below the rate limits only that one request will be limited.

sullen bane
#

ooh makes sense. I just want to be sure I understand you correctly.

#

request 99 - lookup customer product id
request 100 - lookup customer outstanding balance
request 101 - cancel the subscription for the product id

#

request 101 would not go through in this case?

fallow goblet
#

That's a very simplified example that doesn't take into account burst capacity, and there's no timing there, but assuming you mean all those requests happened in a single second then yeah, that's more or less it.

sullen bane
#

interesting

#

i have a cancel page that will allow people to cancel everything they have in 1 shot or separately if they only bought into 1 product id

fallow goblet
#

I can't review all of that code, but if you're making requests sequentially (meaning you're waiting for one request to finish before starting the next one) in that code you should be fine, yeah.

sullen bane
#

ok cool

#

thanks that helps a lot. I thought i would have needed to put a cache timeout on my cancels page like this:

#

def get_client_ip(request):
x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
if x_forwarded_for:
ip = x_forwarded_for.split(',')[0]
else:
ip = request.META.get('REMOTE_ADDR')
return ip

#Put this code in the spot where you submit a password reset email
ip = str(get_client_ip(self.request)) + '_password_reset'
key = hashlib.sha256(ip.encode('utf8')).hexdigest()
if cache.get(key):
remaining_time = (cache.get(key) - timezone.now()).total_seconds()
messages.error(self.request, "Please wait and try again after " + str(int(remaining_time)) + " seconds")
return render(self.request, 'registration/password_reset.html', {'form':form})
else:
cache.delete(key)
cache.set(key, timezone.now() + timezone.timedelta(seconds=60), 60)

fallow goblet
#

It's highly unlikely. One thing to note is that our rate limits in test mode are much lower than in live mode, but still generous. If you test this in test mode and don't run into rate limits you should be just fine in live mode.

sullen bane
#

ok. I was wondering if there was a way to test it or force it to rate limit the requests. I couldn't find anything.

#

Something to brute force it

fallow goblet
#

No, there isn't, and you should not attempt to do so.

#

To be very clear, you should not worry about rate limits. You will likely never be impacted by them, ever. You should make sure you code handles 429 responses from our API and retries requests according to our documentation, but beyond that there's nothing for you to worry about.

sullen bane
#

how would i make my code handle 429 responses?

#

and where would i put something like this? Stripe.max_network_retries = 2

fallow goblet
sullen bane
#

you mean redirect to a custom 429 error page similar to a 404?

fallow goblet
#

You can do that if you wish, but I recommend reading through the section I linked.

#

For the network retries setting, typically you would set that just after initializing the Stripe library with your secret key.

sullen bane
#

I did but you just make it easier to understand 🙂

#

wow really?

#

so something like this:

#

stripe.api_key = settings.STRIPE_PRIVATE_KEY
Stripe.max_network_retries = 2

fallow goblet
#

Yes.

sullen bane
#

Wow never realized that. What is the default if I do not set that network retries?

#

and is there an upper limit?

fallow goblet
#

I don't think network retries are on by default if you don't set that. I don't know of a maximum value, but I think it might be different per language.

sullen bane
#

so the retry is there in case request 101 fails it will retry it again those number of times?

#

so in theory if a retry occurs it takes another second so maybe there should never be any rate limit?

fallow goblet
#

Yeah, the automatic retries will wait a moment and try again.

sullen bane
#

ok great this is all good news to me

#

I think that is all I needed to know. Thanks for clearing a few things up for me and helping me understand this complex topic

fallow goblet
#

Happy to help!

sullen bane
#

have a nice weekend