Hi, That's a great suggestion -- thanks! I don't use task names for anything meaningful currently, so using it as a hashing channel should work great. Now that you've got me thinking about strong encryption vs. just checking local state, I wonder if maybe I should just sign the request payloads.
(When I replied earlier, I had only read the first paragraph. I'm going to blame that on the small display on my phone. Meanwhile, my questions to Google still stands: do you make any guarantees about stripping client-provided headers, and do you have any plans to provide an API for checking the current request's roles in a way that works with task queues? -Patrick On Feb 1, 12:39 pm, Eli Jones <[email protected]> wrote: > 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%2Bunsubscrib > > > > [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%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]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
