Your server might get a request via the javascript they embed from any computer in the world, and there's no way around checking the headers / request params for auth when receiving requests on the endpoint that the library targets.
Even if you provide them a special endpoint (security by obscurity here, but even in combination with actual security of a client secret) which will go down (serve 404, relatively quick and easy) when they've been "unsubscribed", this would not prevent users from triggering the now-failing API call through the JS you gave the developer to embed in their site. The positive aspect of terminating service from your end is that the error bubbles to the third-party site's users, likely preventing them from continuing to use the service and generate API calls. In fact, terminating from your end is the only thing you *can* do, since you can't forcefully delete the JS you gave out, or make the clients "forget" the API endpoint, their key, etc. If you're dealing with a malicious user who wants to repeatedly hit the failing API through site interaction, they won't get far as this is a very inefficient way to conduct a DOS, and if they start targeting you from a specific IP or a group of IPs with bad requests in more serious loads, you'll be dealing with something more on the order of DOS prevention than an auth question. I hope this has helped clarify the boundaries a solution would have to exist within, but things phrased this simply can be deceptive. It would seem after this analysis that you had to pay for the failing requests by checking the auth in a request handler of your app, but the clever solution of Anastasios is to have Cloud Storage handle the rejection calls by the presence or absence of a given resource, avoiding instance-traffic, is quite good. Although you'd have to wonder if the added failure-point of Cloud Storage and dev-time is worth the saved few requests. As discussed above, if somebody really wanted to DOS your instances, they'd do it properly instead of using failing API requests which will not consume as much CPU and network bandwidth anyways as normal requests. On Tuesday, December 15, 2015 at 5:39:47 PM UTC-5, 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/0f8493e4-8c5c-418c-9fce-8f7d96b6566c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
