2

I want from an url:

  • To be called only by the google cron service

  • Not to be called by a user in a web browser

Whats on the google docs didn't work: when the cron service calls the servlet, it also give me a 403 error - forbidden access...

And there is no security related informations regarding the app.yaml file for the flexible env.

Two observation I have made:

  • Google states that "Google App Engine issues Cron requests from the IP address 0.1.0.1". But I got another IP address launching the cron job:

another IP address

  • From this IP address, the HTTP header actually contains the X-Appengine-Cron (with the value true)

Do you have any ideas ?

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
mab
  • 25
  • 3
  • "Whats on the google docs didn't work." What, exactly, didn't work? You state that the `X-Appengine-Cron` header is correctly sent. Handling it would be up to you. `0.1.0.1` to `10.1.0.1` looks like either Google had a typo or something in your stack won't accept the invalid IP. – ceejayoz Mar 13 '17 at 15:48
  • Thanks for the reply! :). When the cron service calls the servlet, it also give me a `403 error - forbidden access`... As `X-Appengine-Cron= True`, it have to got access to the servlet as stated in the docs, right ? – mab Mar 13 '17 at 16:07
  • The 403 is on your end. Make sure you're not mixing up strings `'True'`, `'true'`, and boolean `true`. – ceejayoz Mar 13 '17 at 16:23
  • I'm not mixing it since it's not me who is adding this HTTP header (the `X-Appengine-Cron= True`). It's in Google side, GAP adds this header while calling the servlet from the cron service. I found [a related post](http://stackoverflow.com/questions/36455800/cron-urls-get-a-403-status-on-flexible-environment/42706496#42706496) with no answer. – mab Mar 13 '17 at 16:59
  • Google adds the header. *Handling* it is up to you. It's your service that's responding with a 403 when Google hits the URL. What is it configured to do? – ceejayoz Mar 13 '17 at 17:02
  • FWIW - you can't **prevent** users from requesting a particular URL path in their browsers. What you can do is return errors for such requests. – Dan Cornilescu Mar 13 '17 at 17:48

1 Answers1

4

The referenced doc snippet mentioning the securing method based on login: admin config in the handlers section of the app.yaml file is incorrect - the handlers section is applicable to the (non-java) standard environment app.yaml, not the flexible environment one. So you might want to remove such undocumented config, just to be sure it doesn't have some unexpected/undesired negative effect.

Checking just the X-Appengine-Cron should be sufficient enough: it can only be set by the cron service of your app. From Securing URLs for cron:

Requests from the Cron Service will also contain a HTTP header:

X-Appengine-Cron: true

The X-Appengine-Cron header is set internally by Google App Engine. If your request handler finds this header it can trust that the request is a cron request. If the header is present in an external user request to your app, it is stripped, except for requests from logged in administrators of the application, who are allowed to set the header for testing purposes.

As for why exactly the response to the cron request is 403 - you should show your handler code which is (most likely) the one responsible for building the reply.

Dan Cornilescu
  • 39,470
  • 12
  • 57
  • 97
  • Thank you a lot for your response Dan! The thing is that I don't see at all how to handle the http request sent by appengine. I need to check if the X-Appengine-Cron is set to true in my servlet or in another handler script ? If so, what's next ? What should I put in the response to tell my servlet to run after checking the header is actually set to true ? If not, what does the handler script look like ? – mab Mar 14 '17 at 15:12
  • Assuming the servlet is what handles the request (I'm not 100% certain about how java apps work, I'm using python). Then yes, the header check is done in there. And the servlet is already running, after the header check just execute what has to be executed. – Dan Cornilescu Mar 14 '17 at 16:41