Hi hawkett,
The bug you found earlier, with Task Queue accesses returning 302s instead
of executing correctly, is definitely a bug in the dev_appserver. Can you
please file a bug on the issue tracker?
On Mon, Jun 22, 2009 at 11:18 PM, hawkett <hawk...@gmail.com> wrote:
>
> Hi,
>
> I've deployed an app to do some tests on live app engine, and the
> following code
>
> currentUser = users.get_current_user()
> if currentUser is not None:
> logging.info("Current User - ID: %s, email: %s, nickname: %s" %
> (currentUser.user_id(), currentUser.email(), currentUser.nickname()))
>
> logging.info("is admin? %s" % users.is_current_user_admin())
>
> yields: 'is admin? False'
>
> as the total log output. This is code that is run directly from a
> handler in app.yaml that specified - 'login:admin'
>
> This represents a pretty big problem - it means you can't rely on
> 'login:admin' to produce a user that is an admin.
On the contrary - only administrators and the system itself (eg, cron and
task queue services) will be able to access "login: admin" handlers.
However, when access is by a service, no user is specified, so
"is_current_user_admin()" will naturally return False, not because it's not
an admin access, but because there's no current user.
> I'm guessing that
> the goal of the Task Queue API is to be usable on generic URLs - e.g.
> in a RESTful application, the full CRUD (and more) functionality is
> exposed via a dynamic set of URL's that more than likely are not
> specifically for the Task Queue API - however the above situation
> means you really have to code explicitly for the Task Queue API,
> because the meaning of the directives in app.yaml is not reliable. It
> looks like cron functionality works like this as well, and that has
> been around for a while. Use cases such as write-behind outlined in
> Brett's IO talk are significantly limited by being unable to predict
> whether you will get a user or not (especially if you intend to hit
> RESTful URI that could just as easily be hit by real users). Sure,
> there are ways to code around it, but it's not pretty.
I'm not sure I see the problem - what user would you expect to see listed
when a webhook is being called by the cron or task queue system?
-Nick Johnson
>
> I've added a defect to the issue tracker here -
> http://code.google.com/p/googleappengine/issues/detail?id=1742
>
> I'm keen to understand how google sees this situation, and whether the
> current situation is here to stay, or something short term to deliver
> the functionality early. Cheers,
>
> 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
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
