Sure - just before I do, the following may indicate that this isn't a bug -
If I am also logged in to the application in another tab, as an administrator, then when I hit 'run' the task fires successfully, or at least the stub fires and records a 200. So it would appear I need to also be logged in as an admin. While this makes some sense, it doesn't really mirror the behaviour on GAE, as the task queue won't have the benefit of this authentication cookie - what user does the live system use to execute protected URL's? Colin On Jun 22, 4:31 pm, "Nick Johnson (Google)" <nick.john...@google.com> wrote: > Hi hawkett, > > My mistake. This sounds like a bug in the SDK - can you please file a bug? > > -Nick Johnson > > > > On Mon, Jun 22, 2009 at 4:25 PM, hawkett <hawk...@gmail.com> wrote: > > > Hi Nick, > > > In my SDK (just the normal mac download), I can inspect the queue in > > admin console, and have a 'run' and 'delete' button next to each task > > in the queue. When I press 'run', the task fires, my server receives > > the request, and returns the 302. > > > Colin > > > On Jun 22, 4:15 pm, "Nick Johnson (Google)" <nick.john...@google.com> > > wrote: > > > Hi hawkett, > > > > In the current release of the SDK, the Task Queue stub simply logs tasks > > to > > > be executed, and doesn't actually execute them. How are you executing > > these > > > tasks? > > > > -Nick Johnson > > > > On Mon, Jun 22, 2009 at 3:46 PM, hawkett <hawk...@gmail.com> wrote: > > > > > Hi, > > > > > I'm running into some issues trying to use the Task Queue API with > > > > restricted access URL's defined in app.yaml - when a URL is defined as > > > > either 'login: admin' or 'login: required', when the task fires it is > > > > receiving a 302 - which I assume is a redirect to the login page. I'm > > > > just running this on the SDK at the moment, but I was expecting at > > > > least the 'login: admin' url to work, based on the following comment > > > > from this page > > > >http://code.google.com/appengine/docs/python/taskqueue/overview.html > > > > > 'If a task performs sensitive operations (such as modifying important > > > > data), the developer may wish to protect the worker URL to prevent a > > > > malicious external user from calling it directly. This is possible by > > > > marking the worker URL as admin-only in the app configuration.' > > > > > I figure I'm probably doing something dumb, but I had expected the > > > > tasks to be executed as some sort of system user, so that either > > > > 'login: required' or 'login: admin' would work - perhaps even being > > > > able to specify the email and nickname of the system user as app.yaml > > > > configuration. Another alternative would be if there was a mechanism > > > > to create an auth token to supply when the task is created. e.g. > > > > users.current_user_auth_token() to execute the task as the current > > > > user. > > > > > So I guess the broader question is - where does the task queue get the > > > > 'run_as' user, or if there isn't one, what's the mechanism for hitting > > > > a 'login: admin' worker URL? > > > > > Most apps should be able to expect a call to users.get_current_user() > > > > to return a user object in code protected by 'login: admin'. > > > > > Thanks, > > > > > Colin > > > > -- > > > Nick Johnson, App Engine Developer Programs Engineer > > > Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration > > Number: > > > 368047 > > -- > Nick Johnson, App Engine Developer Programs Engineer > 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-appengine@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 -~----------~----~----~----~------~----~------~--~---
