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.
