Hi Nick,
Bug filed - http://code.google.com/p/googleappengine/issues/detail?id=1751
> 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?
The problem is that the handler code needs to have an understanding of
the particular calling client. This tightly couples the handler code
to the calling mechanism. I totally wrecks the idea that the protocol
should allow loose coupling of the two end points. From my
perspective, that's bad architecture. If I explicitly say I need a
user (admin or otherwise) to access a URI, then the system should make
sure that URI is not accessed unless there is a user. Once you start
introducing edge cases - 'It's true unless this, or unless that', the
platform becomes 'clunky'. app.yml is an interface contract, and
currently asynch breaks that contract. That contract is far more
important than one client's (GAE system) difficulty (which user?)
conforming to it. My 2c anyway. Thanks,
Colin
On Jun 23, 10:46 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
