One more idea, NP: Your JS code at first page-load asks a third-party service if it's OK to use the API. For example, you host one public file for each user/site under some randomized URL unique to every site. The file contains the domain-name and API key (I guess, the API key is quite public anyway). If those do match, the JS code will know that it can send requests to your API. Again, cache the result, so every client will ask only once per visit.
If you want to exclude all clients of that site, you delete the site's file on GCS. The JS code receives a 404 and doesn't even touch your API and instance hours. You can have your app handle the files operations automatically per site / API key. Downside is, additional time after page-load and that it adds another point of failure (e.g. outage of GCS). But for the latter case, your JS code could handle 500 errors gracefully and just send requests to the API, especially if you care more about availability of your API service than "unauthorized" usage. Of course, you would need to compare the potential costs of both ideas. On Wednesday, December 16, 2015 at 1:09:40 AM UTC+1, NP wrote: > > Hi Anastasios, > > Thanks for your response. I currently have a variation of what you > suggested. I have list of 'paused' sites and the JS call to my application > includes the domain name of the website. When the JS call comes in, my > handler first checks if it's in the list of 'paused' sites and if so, it > terminates with a 403 error. I ran some testing with a user whose page is > viewed about 40,000 times a day. This basically means at least 40,000 hits > to my instance. I worry that this is a big number especially if this > happens with multiple sites. This is why I was wondering if there's any way > to prevent access to my site. > > You also suggested - > > - Since it seems to be your own JS code: see if you can gracefully > handle the Over-Quota error or the Indefinite-Terminate errors *and > cache the result, so the JS client will not send subsequent requests and > cause unnecessary resources* > > > Can you explain the part in bold? > > Thanks > NP > > On Tuesday, December 15, 2015 at 3:30:41 PM UTC-8, Anastasios Hatzis wrote: >> >> Hi NP, >> >> just a few thoughts: >> >> - I agree that ddos.yaml won't help you in your case, especially if >> IP addresses change consistently >> - Provider per-user API keys that must be used by the javascript code >> for each request >> - In your GAE app, the API request handlers should first check for >> the API key and immediately terminate with a specific HTTP status code >> and >> error message that communicate to the JS client that the AP key is >> temporarily over quota or terminated indefinitely; make this part as >> efficient as possible, so you loose as little instance runtime as possible >> - Since it seems to be your own JS code: see if you can gracefully >> handle the Over-Quota error or the Indefinite-Terminate errors and cache >> the result, so the JS client will not send subsequent requests and cause >> unnecessary resources >> - I guess, your app will also receive the original host-name that >> hosted the JS code, so you could store the host-name (and API key?); >> automatically email or contact the user that registered the host or API >> key >> to inform about troubleshooting steps >> - I'm not sure if it is possible to have the JS code delivered by >> your app (with API keys validation), so there will be just a 404 if the >> API >> key is over-quote / terminated; but eventually cross-site scripting >> vulnerability would prevent this; I hope someone with more experience in >> JS >> can shed some light on this >> - If you expect that too many users will not remove the JS code even >> after the API key has expired, you might consider if there is anything >> you >> could add to the JS code, that in this case, the users of that site will >> have an experience that will have the site operator be cooperative (e.g. >> blanking the page, or showing a huge red warning modal); that might be >> very >> dangerous though (for example if there is an error in your client code or >> server code or there is a temporary outage etc. you would make your users >> very angry or maybe you will be accountable for damages) >> >> >> On Tuesday, December 15, 2015 at 11:39:47 PM UTC+1, NP wrote: >>> >>> Hello all, >>> >>> I'm working on a design (in python) where my users will embed a piece of >>> javascript code on their website. This javascript code will call my >>> application which then provides service to my users. An example of this >>> approach is signing up for Google Analytics or Google Ads. Google gives you >>> a piece of javascript code which you embed on your website and when users >>> load your page, the javascript code calls Google Servers. >>> >>> I'm trying to figure out what to do if a user is no longer using my >>> service but forgets to delete the javascript code from their pages. Is >>> their a way to prevent such sites from accessing my site without incurring >>> a hit on my server? The option I can think of right now is to have my code >>> catch the request and then throttle it but that still involves a hit to my >>> server and if my client's website is being accessed by thousands of users, >>> the hits to my server becomes considerable. >>> I know that Google App engine has a Denial of Service Protection but as >>> far as I know, this works only for IP address. >>> >>> Thanks >>> >> -- HATZIS Edelstahlbearbeitung GmbH Hojen 2 87490 Haldenwang (Allgäu) Germany Handelsregister Kempten (Allgäu): HRB 4204 Geschäftsführer: Paulos Hatzis, Charalampos Hatzis Umsatzsteuer-Identifikationsnummer: DE 128791802 GLN: 42 504331 0000 6 http://www.hatzis.de/ -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/60a72a58-4130-4d41-a35b-c6819ac887c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
