The only thing to look out for when naming Tasks is.. Task names are unique for a certain time period (I think its 7 days [I'm writing this on my phone so I won't be verifying that :) ]).
This makes sure a task with the same name doesn't get added to the queue twice due to any errors. On 2/2/10, Patrick Linskey <[email protected]> wrote: > 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. > > -- Sent from my mobile device -- 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.
