lat9 / access_blocker

Access Blocker (a pseudo-recapcha)
Other
0 stars 1 forks source link

Quota has been depleted #2

Open Pan2020 opened 5 years ago

Pan2020 commented 5 years ago

Free tier gives 1,500 requests. Indeed, for my case... I may have to enter into paid plan.

But, based on timing... I do feel there is something wrong.

On Visitor History:

Day | Sessions - Total
05/06/2019 | 870 - 1206
05/05/2019 | 1487 - 2084
05/04/2019 | 1460 - 2192
05/03/2019 | 1555 - 2406
05/02/2019 | 1687 - 2832
05/01/2019 | 1764 - 3108
*04/30/2019 | 19154 - 83263
04/29/2019 | 1575 - 2882

*April 30th, 2019... it has extremely high number of sessions due to Security Metrics (aka. the company who checking on PCI compliance) scanning the website...

However, based on timing I check on past emails... "You have made 1500 requests. All subsequent calls will be blocked." 4/29 16:23 Your quota resets in the next 18 hours and 52 minutes. 4/30 11:55 Your quota resets in the next 23 hours and 22 minutes. 5/01 16:15 Your quota resets in the next 19 hours and 3 minutes. 5/02 16:30 Your quota resets in the next 18 hours and 50 minutes. 5/03 11:21 Your quota resets in the next 1 second. 5/03 17:06 Your quota resets in the next 18 hours and 15 minutes. 5/04 11:28 Your quota resets in the next 23 hours and 54 minutes. 5/05 17:13 Your quota resets in the next 18 hours and 11 minutes.

I suspect that the reset time is roughly the time when I signed up (11:21 in the morning). However, it ran out free tier rather quick! Like within 6 hours on average! Some days were ran out within minutes! April 30th is expected due to PCI scan. (6 minutes after reset) May 4th however.... (exhausted in 38 minutes after reset)

So I went to API FAQs for possible reasons for excessive calls. https://docs.ipdata.co/overview/faqs

I've received a notification that I've exhausted my quota and it's not possible This can be particularly frustrating especially when your Google Analytics data doesn't match your usage. We can help you trace the origin of the traffic from our end. The reasons for this include; Calling the API on every page view. We recommend calling the API once per user session and storing the response in a cookie. Internal usage, you might have set your organisation's internal network to be excluded from Google Analytics and builds or automatic test suites running from that range are generating excessive requests Bots and scrapers Some Solutions for this; Reaching out to us to help you trace the source of your traffic (paid users) Identifying bots from the user agent and not calling the API when it's a bot Caching user location per session to avoid excessive calls to the API Restricting use of your API Key to a whitelist of server IP Addresses or specific domains. This is the most secure way to access the API (paid users)

So I wonder if this add-on really consider this part, where spiders (e.g. Google) or internal usage (e.g. I check out Contact Us page) would NOT be count against the API instead of drain the usages like crazy...

I'm not entirely sure if CloudFlare (using CDN) can influence the request calls as well, but it did not mentioned above...

lat9 commented 5 years ago

Other than the configured blocked IP addresses, which are checked prior to accessing the ipData server, the plugin does not check for spiders as that list is ever growing.

Pan2020 commented 5 years ago

But consider that Zen Cart can identify Spider in the Admin panel in "Who's Online" panel. Can't you use the Zen Cart's code in the same manner to not allow spider to trigger the usage of ipData? (Maybe by "host" or "user agent" as surely IP addresses are keep changing...)