Great, thanks! Do you have any documentation to this effect? An enumeration of the headers that you strip and add, and in what contexts, would make a great contribution to your existing sections on securing an application in Python / Java, or a new security FAQ section.
Also, I noticed that the dev appserver does not set the X-AppEngine headers when invoking task queues. It's not a big deal, since I can detect that the dev server in other ways (including checking for the "X-Google-DevAppserver-SkipAdminCheck", if I knew that it was being stripped). But it'd be nice if the environments were more similar. Thanks for the info, -Patrick On Feb 2, 2:35 am, "Nick Johnson (Google)" <nick.john...@google.com> wrote: > Hi Patrick, > > Filtering out X-AppEngine prefixed headers is intentional, and we certainly > expect to continue doing so. > > -Nick Johnson > > > > > > On Mon, Feb 1, 2010 at 8:29 PM, Patrick Linskey <plins...@gmail.com> wrote: > > > (and Require Admin login isn't enough) > > > That would be enough, but the only way to do that is to put the > > limitation in the web.xml file, which is pretty far away from the > > servlet in question. I want to make sure that someone doesn't > > accidentally mis-configure the web.xml file to remove the admin > > restriction. And I'd really rather not parse web.xml and apply all the > > appropriate rules to do so. > > > Also, I don't know whether or not Google guarantees that the X- > > AppEngine-TaskName header is stripped from malicious incoming > > requests. It looks like it does, but that's just based on my > > observations. > > > Thanks, > > > -Patrick > > > On Feb 1, 11:02 am, Eli Jones <eli.jo...@gmail.com> wrote: > > > If you have a compelling reason for really locking down the task queue > > url > > > (and Require Admin login isn't enough), you could create a mechanism that > > > creates a task name for each queued task.. and the task verifies that its > > > name is "correct". > > > > You could have the task use the X-AppEngine-TaskName header to check its > > > name.. > > > > So.. when you add a task to the queue.. you do something like this: > > > > taskName = getUniqueTaskName() > > > nameHash = getHash(taskName) > > > > taskqueue.add(url = '/myTaskQueue', countdown = 0, > > > name = taskName, > > > params = {'nameHash' : nameHash}) > > > > and.. in the first part of the /myTaskQueue code.. you could have it > > verify > > > that the 'nameHash' param is equal to getHash() of the TaskName you grab > > > from the header.. > > > > On Sat, Jan 30, 2010 at 4:07 PM, Patrick Linskey <plins...@gmail.com> > > wrote: > > > > Hi, > > > > > I'd like to programmatically ensure that my task queue servlets are > > > > only invoked via the task queue. I've got a security constraint in my > > > > web.xml, but I'd like to also check in code to avoid any potential mis- > > > > configuration in the future. > > > > > Is there any supported means to do such a check? > > > > > I tried looking at the contents of the HttpServletRequest (isUserInRole > > > > (), getAuthType(), getUserPrincipal(), getRemoteName()), to no avail. > > > > I also tried UserServiceFactory.getUserService().isAdmin(), but > > > > received an exception informing me that no user was logged in. > > > > > I can see that there are a number of task queue-specific HTTP headers. > > > > Currently, I'm checking that X-AppEngine-TaskRetryCount is present, > > > > and if so, assuming that the request has come from the task queue and > > > > that it's therefore safe to process. Empirically, it looks like GAE > > > > strips out the X-AppEngine-TaskRetryCount header when I specify it in > > > > a curl-sourced request. Is this a safe assumption to rely on? Are > > > > there plans to document a reliable way to ensure servlet security in a > > > > task queue environment? Is there something else that I'm missing? > > > > > Also, in an ideal world, it'd be nice if request.isUserInRole("admin") > > > > would return true at the appropriate times. > > > > > Thanks, > > > > > -Patrick > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google App Engine" group. > > > > To post to this group, send email to google-appengine@googlegroups.com > > . > > > > To unsubscribe from this group, send email to > > > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > > > > e...@googlegroups.com><google-appengine%2Bunsubscrib > > e...@googlegroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to google-appeng...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib > > e...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. > > -- > Nick Johnson, Developer Programs Engineer, App Engine > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: > 368047 -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.