That's why you have to use the TaskName and Hash method to verify that a Task was added to the queue in an orthodox manner.
Unless someone knows the hash scheme you are using for TaskNames.. they will not be able to send in a (TaskName,getHash(TaskName)) pair that would get validated when the task started running.. Let me know if I'm not being clear in my suggestion.. this should do exactly what you want.. it would 100% prevent a person from accidentally visiting the URL and running a task (since it checks for the TaskName header).. and it would pretty much prevent some random person from trying to impersonate a task by sending a Post to the task URL.. They would have to know the correct hash to send along with the TaskName they are spoofing.. On Mon, Feb 1, 2010 at 3:29 PM, Patrick Linskey <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 [email protected] > . > > > To unsubscribe from this group, send email to > > > [email protected]<google-appengine%[email protected]><google-appengine%2Bunsubscrib > [email protected]> > > > . > > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
