For a laravel application that uses stripe, this request https://r.stripe.com/0 gets fired multiple times like so:
These requests got fired right after I refreshed the homepage.
The problem is that I recently got a 429 too many requests error in my live server. This is pretty rare but I suspect it has something to do with stripe since I read about rate-limiting in stripe.
Since I am new to stripe and I got this project handed over midway, I had some questions:
Is there any relation between the 429 error and these stripe requests? Or is this something to do with the way the system is built?
If it's the former, how would one resolve the issue? Maybe disable the security checks (cause I read somewhere that these requests were stripe security checks), or maybe increase the rate limit from stripe in some way?
I searched extensively about this but couldn't find any relevant posts anywhere, maybe because it's a very trivial problem. I would be grateful if someone who has faced this or knows about this can enlighten me.
Related
I have a web application (Angular front, Laravel backend API). In that there is a section where I have messaging system. Basically four user roles can post and read messages.
When a user logged in I needs to check every 10 seconds to see if there are new messages for any user of any role(out of 4 roles).
This works fine but from time to time I get http status code of 429 Too many request. I have no idea what is the reason. Anyone have an idea of what is the reason or can point me to the right direction in order to fix this?
Note: I have a custom field system build and I use that to hold extra data of messages. I notice that when i fetch messages considerable number of models related to custom fields also quarried. Can this be a reason?
I found the solution and here are my steps.
I needed to find all my request going to the API, for that I installed this package API logger. Using this I examined the requests and there I found some request made to the API over and over.
I corrected the requests made to the API and the issue seems to fixed.
We have a sales tracker app. In this app, we collect all analytic data from 5 different analytic accounts (websites) and creating reports. It was working till today morning itself. Now it shows some errors like 500 Backend Error:
PHP Fatal error: Uncaught Google_Service_Exception: {"error":{"errors":[{"domain":"global","reason":"backendError","message":"Backend Error"}],"code":500,"message":"Backend Error"}}
500 errors are catch all errors that normally mean that there is something on the servers end that is the issue. If you check the documentation you will see the above comment. Google says that they dont want you to retry that error. However if you scroll down a bit more in the documentation you will find this section.
However we find the following as well.
However there is nothing with both "code":500,"message":"Backend Error"
backoff
There are a number of error messages where backoff would work.
With a python example that includes
This is because the Google analytics api is slightly different than the other Google apis the way it returns errors is not the same and in most cases its better. The reason for this is that backend error can be cause by flood protection. Not often but it can happen mostly around the hour. You should never run a large script on the hour because then you are competing with everyone that has cron jobs set up to extract data every hour.
I normally only use backoff for 'userRateLimitExceeded', 'quotaExceeded', 'internalServerError' errors not for 'backendError' but Google is stating it in their documentation so it may be worth a shot.
In the mean time i am going to send an email off to the team to get some clarification on the documentation.
500,"message":"Backend Error"
As for the message above i have seen this a few times and its often related to an issue on Googles end. Give back off a try while i wait to hear back from the team.
So I have a problem with rate limiting in a Laravel project for a China project. All the users are from China. The scenario is that an authenticated user manage to submit 10 post requests within a second? How can I prevent this to happen?
I have tried using laravel Throttle feature but I am not sure whether if it will work if I set it to milliseconds. Are there any suggestions on how I could counter this problem?
So I'm trying to implement a payment solution for my website and after quite a bit of research, I'm still lacking a complete solution. I'm running Laravel 5.0 and need general shopping cart payment functionality. I thought I would post this to try to create a reference to help others that may be having this issue. I got as far as getting test transactions into the Paypal sandbox and that's where the brick wall has seemed to come in, but a complete overview would be helpful. I’ll list my issues that I need to overcome in order to issues some run into.
Issues needing to be resolved to complete the payment solution implementation
My biggest issue with what I've seen has been receiving the
notification of successful payment processing back, but I'll walk
through what I've seen thus far. I'm not sure how to set up a listener or other methods of detecting a correct payment processing
Dealing with Credit Card information when I’m trying to avoid it
for the time being – I’d like that to be done on the gateway website
Potentially kicking off some of the calls to these APIs in Laravel
when the user checks out
I’m trying to move items to my server, but the development is being
done locally which creates an added issue
The options
There’s simply Paypal
I’ve taken the basic form implementation as far as getting payments into Paypal, but I can’t seem to get payments out. I’ve tried the returnURL and that doesn’t seem to work
I do not necessarily like this option because it seems to be leaving a lot of information in the form that would seem to be better kept private on the server
I’d like to use something complete on git but I seem to find the documentation incomplete
https://github.com/thephpleague/omnipay-paypal
--Not sure how to implement this in laravel
https://github.com/ignited/laravel-omnipay
--doesn’t appear to be being used
https://github.com/net-shell/laravel-paypal
https://github.com/anouarabdsslm/laravel-paypalpayment
--The card information is not intuitive here as that’s what going to
paypal’s supposed to manage
It would be nice to use Paypal express but I don’t see a ton of resources specifically for that.
There's Aimeos.
I don't necessarily feel safe with manually implementing the vsrf
protection and it doesn't seem to offer that much more on the payment
front than
I’m open to others that are complete and charge similar fees to Paypal
Stripe doesn’t work for me. I’m not doing a basic subscription
Any complete thoughts would be greatly appreciated as documentation left short has caused issues in this case. Thanks!
This PayPal PHP SDK will make all of the PayPal classic API calls very quick and easy for you. It's available on Packagist/Composer and can be applied to Laravel very easily.
It supports Express Checkout, Payments Pro, Invoicing, Transaction Search, Transaction Details, Refunds, etc.
This is done in Laravel 4, but I had begun this "PayPal Glass" project a while back to show how the class library / sdk can essentially replicate everything you can do within a PayPal account. Here it is running on my local test server.
So yeah, that SDK should be able to handle everything you need to do with PayPal inside a Laravel project.
We have Intermec CK71 mobile devices (WiFi). There will always be a scenario in which the device sends a request (GET, PUT, or POST), then loses connection. What methods can we use to prevent duplicate PUTs or POSTs? How does the client device know whether or not the server processed its request before losing the connection?
I have seen similar posts like this but the marked answer doesn't go into much detail. I'm not even sure where to begin. Should I be looking into caching (ETag, last modified), or some type of handshaking?
The client device has the .Net Compact Framework 3.5 on it and is hitting the server via its Web API 2 endpoints.
If someone can point me to the right direction or offer any suggestions it would be much appreciated. Thanks.
I am not using REST but as far as I read the information there is no easy way to get an acknowledge and avoid duplicate POST.
As with other high level API frameworks you are tied to what the API offers and it looks like the designers did not think about connection aborts.
The easiest way to workaround this seems to use an unique ID with every post and check the server for knowing these UID before re-posting. If the server does not response with OK for an POST, you have to assume the connection has broken or other things went wrong. Then query the server for the UID you posted to know if the pervious POST was succesful before you try another POST with the same data and UID.
Possibly there is some transaction encapsulation available with REST as available for sql server. A 'transaction' protocol would ensure that a POST has been processed succesfully or will be 'rolled' back, if something failed.
Sorry, but I do not know much about REST.