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 >> > -- 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/0ad4cd1e-28a0-4950-9e9d-68302fd9c59b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
