We have application named Milekeeper, which relays users to send invitations to race to his or hers friends.
We are sending these race participation invites to feed.
After some hardcore testing we received this error: "FbGraph::InvalidRequest OauthException :: (#341) Feed action request limits reached".
What are limits and how can we increase these????
You cannot increase these limits.
These limits were imposed to prevent apps from spamming Facebook. If you are getting this error, it means that you are reaching the limit. You are simply not allowed to post more. These limits are expressed as "buckets" and can be viewed on the insights page for your app if you want to see how much you can post.
I think regular users will not encounter this error, unless you are actually forcing a user to publish a big number posts every day, which should be frowned upon.
Related
I run an email forwarding service (https://kopi.cloud).
I'm investigating the feasibility of building a feature to allow users to "bring their own domain".
It seems like this should work fine with SES, except there are limits on total number of rules and total number of recipients (see https://docs.aws.amazon.com/ses/latest/DeveloperGuide/limits.html)
With the currently limits on rules and recipients, I could pack the subscriber domains into the receipt rules and Kopi could support up to about 10,000 separate domains.
10K domains will be plenty for a while, I don't expect that many people will actually want to bring their own domain (I reckon most people who'd want this would just go ahead and do their own forwarding), so I'm going to go ahead prototyping the feature.
But I need to check if these limits are "soft limits", like the sending limits that can be raised on request; or "hard limits", where no increase is possible.
I'm still going to prototype the feature and if it were to be wildly successful, I guess I could jury-rig something together with multiple accounts or some other shennanigans.
So my question: "Is it possible to get the SES receiving rule limits raised?"
Answer from AWS support, as of June 2019 - "these limits are a hard limit and cannot be increased at the moment".
There is an outstanding request to raise them though.
https://forums.aws.amazon.com/thread.jspa?threadID=303902
Following is the screenshot of the server activity log.I can see that many requests are automatically raised in the server.How can I avoid this.?
It looks like someone is fuzzing your website and scanning to find any common file names or extensions that commonly have security vulnerabilities. One way to limit this behaviour is to implement rate limiting whereby you might limit the number of requests a user makes that result in HTTP 404 Not Found during some time period before giving them a temporary ban. Note: this solution doesn't stop this from happening but it does buy you time and may deter the attacker or researcher
I am going to use AWS Cognito User Pool product as user directory for application and have several questions:
Is Amazon throttle request to Cognito User Pool and if yes what is the rate limit of calls to get throttled?
How Cognito defends against bruteforce attack on login/password?
After couple of hours search I found this two exceptions in source code:
TooManyFailedAttemptsException This exception gets thrown when the
user has made too many failed attempts for a given action (e.g., sign
in).
HTTP Status Code: 400
TooManyRequestsException This exception gets thrown when the user has
made too many requests for a given operation.
HTTP Status Code: 400
Also, I tried to log in with wrong credentials to test limits, I get NotAuthorizedException: Password attempts exceeded exception after 5. attempt.
In a similar scenario, I tried to brute force to forgot password but after 10 failed attempt I got LimitExceededException: Attempt limit exceeded, please try after some time.
I think that is how they do it.
Yes, Cognito User Pools protects against brute force attacks by using various security mechanisms. Throttling is one of those of mechanisms. We do not share limits as they vary dynamically.
This contains the latest documentation on the lockout policies for Cognito.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html
We allow five failed sign-in attempts. After that we start temporary lockouts with exponentially increasing times starting at 1 second and doubling after each failed attempt up to about 15 minutes. Attempts during a temporary lockout period are ignored. After the temporary lockout period, if the next attempt fails, a new temporary lockout starts with twice the duration as the last. Waiting about 15 minutes without any attempts will also reset the temporary lockout. Please note that this behavior is subject to change.
Rather than (or in addition to) focusing on bruteforcing the login endpoint, I think forgot password flow deserves some attention.
Forgot password email contains a 6-digit code that can be used to set new password.
This code is valid for 1 hour. User Pools code validity resource quotas.
In my tests I could make 5 attempts to set new password within an hour for a single user before throttling came into effect (LimitExceededException: Attempt limit exceeded, please try after some time.)
Now, if I do the math correctly, there are 1000000 possible values for a code (from my tests I never saw codes starting with 0 so there may be less). You have 5 attempts/hr to guess the code. So each hour you have 5/1000000*100=0.0005% chance to succeed with resetting the password without knowing the code.
Is this a small chance? It seems so.
Considering a large-scale attack bruteforcing multiple users with retries concurrently should I sleep well at night? I don't know!
To solve the issue once and for all, why can't Cognito use longer codes that are hard to guess (I want to sleep well at night). Maybe it has something to do with the fact that the same codes mechanism is used in text messages. I wish there was an official comment.
We want to collect some metrics about our client public Facebook pages (~1-5K users) on a daily (or weekly) basis.
I'm talking about 3-5 typical metrics : "likes", "fan posts" etc.
I understand that according to the "Rate Limiting on the Graph API" documentation [1] it's possible to have 200 calls per 1 hour.
For now we don't have any FB public application that can help us to increase this limit. To generate application token we will create it to but I doubt it will have a lot of users.
Does anybody know will we have problems with rate limit exceptions while invoking Graph API more than 200 times per 60 min.?
I guess our expected rate is 5-10K calls per 60 min (once a day).
Phrase from the documentation [1] "Rate limiting in the FB Graph API is encountered only in rare circumstances" gives me hope that it won't be a problem.
Thank you!
[1] https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
You won't have any problems initially. Facebook does not necessarily block apps immediately for being over the limits.
As per their documentation
If your app is making enough calls to be considered for rate limiting by our system, we return an X-App-Usage HTTP header
So, if you don't get any X-App-Usage header,Then your app hasn't be considered "worthy" of throttling by their automated systems yet.
So it would be best to check for this header, while making your api requests. Once you start receiving this Header, it would be best change your frequency of the API calls or give a timeout.
Imagine 3 system components:
1. External ecommerce web service to process credit card transactions
2. Local Database to store processing results
3. Local UI (or win service) to perform payment processing of the customer order document
The external web service is obviously not transactional, so how to guarantee:
1. results to be eventually persisted to database when received from web service even in case the database is not accessible at that moment(network issue, db timeout)
2. prevent clients from processing the customer order while payment initiated by other client but results not successfully persisted to database yet(and waiting in some kind of recovery queue)
The aim is to do processing having non transactional system components and guarantee the transaction won't be repeated by other process in case of failure.
(please look at it in the context of post sell payment processing, where multiple operators might attempt manual payment processing; not web checkout application)
Ask the payment processor whether they can detect duplicate transactions based on an order ID you supply. Then if you are unable to store the response due to a database failure, you can safely resubmit the request without fear of double-charging (at least one PSP I've used returned the same response/auth code in this scenario, along with a flag to say that this was a duplicate).
Alternatively, just set a flag on your order immediately before attempting payment, and don't attempt payment if the flag was already set. If an error then occurs during payment, you can investigate and fix the data at your leisure.
I'd be reluctant to go down the route of trying to automatically cancel the order and resubmitting, as this just gets confusing (e.g. what if cancelling fails - should you retry or not?). Best to keep the logic simple so when something goes wrong you know exactly where you stand.
In any system like this, you need robust error handling and error reporting. This is doubly true when it comes to dealing with payments, where you absolutely do not want to accidentaly take someone's money and not deliver the goods.
Because you're outsourcing your payment handling to a 3rd party, you're ultimately very reliant on the gateway having robust error handling and reporting systems.
In general then, you hand off control to the payment gateway and start a task that waits for a response from the gateway, which is either 'payment accepted' or 'payment declined'. When you get that response you move onto the next step in your process and everything is good.
When you don't get a response at all (time out), or the response is invalid, then how you proceed very much depends on the payment gateway:
If the gateway supports it send a 'cancel payment' style request. If the payment cancels successfully then you probably want to send the user to a 'sorry, please try again' style page.
If the gateway doesn't support canceling, or you have no communications to the gateway then you will need to manually (in person, such as telephone) contact the 3rd party to discover what went wrong and how to proceed. To aid this you need to dump as much detail as you have to error logs, such as date/time, customer id, transaction value, product ids etc.
Once you're back on your site (and payment is accepted) then you're much more in control of errors, but in brief if you cant complete the order, then you should either dump the details to disk (such as csv file for manual handling) or contact the gateway to cancel the payment.
Its also worth having a system in place to track errors as they occur, and if an excessive number occur then consider what should happen. If its a high traffic site for example you may want to temporarily prevent further customers from placing orders whilst the issue is investigated.
Distributed messaging.
When your payment gateway returns submit a message to a durable queue that guarantees a handler will eventually get it and process it. The handler would update the database. Should failure occur at that point the handler can leave the message in the queue or repost it to the queue, or post an alternate message.
Should something occur later that invalidates the transaction, another message could be queued to "undo" the change.
There's a fair amount of buzz lately about eventual consistency and distribute messaging. NServiceBus is the new component hotness. I suggest looking into this, I know we are.