i agree with colin on the "no user = admin" fishy-ness. it would be nice if the task system just set the current user to admin. that way, if for some reason your task url endpoint got out on the web (although not likely), you could safely ignore the requests with no user. right now you'd have no way of telling (hmm, request headers or ip address might do)
for running tasks under the user who started them, I would agree that adding this info to the payload is sufficient cheers brian On Jun 25, 8:49 am, hawkett <[email protected]> wrote: > Hi Tony, > > That's the second of the options I listed in the defect/feature > request > > http://code.google.com/p/googleappengine/issues/detail?id=1742 > > The first is to have the system run as a 'special' user specified in > app.yaml. > > Another way of looking at the problem, perhaps, is that the current > asynch implementation is asking us to change this code > > if users.is_current_user_admin(): > # Do privileged stuff > > to this > > currentUser = users.get_current_user() > if users.is_current_user_admin() or currentUser is None: > # Do privileged stuff > > i.e. no user = admin user, and that smells funny to me. I'm also > thinking we need to be able to call URL's protected in app.yaml with > 'login: required', as this is going to be a common use case - a place > where many app's urls naturally reside. Thanks, > > Colin > > On Jun 24, 12:52 am, Tony <[email protected]> wrote: > > > > > I think (correct me if I'm wrong) that what Colin is saying is that if > > User A is logged in, and performs an action on a page which enqueues a > > task, and the task hits a webhook, the webhook should be able to > > operate just as if User A had logged in, and hit the webhook url (so > > users.get_current_user() should return the user that enqueued the > > task). > > > The workaround seems pretty easy, though, just pass the required > > information in the payload: "if user is None: user = db.get(request.get > > ('userkey'))," or "if user is None: username = db.get(request.get > > ('username'))" or what have you. > > > Or maybe he's just saying you should be able to assign more granular > > permissions like: > > > - url: /hook > > login: [admin, cron] > > > Or maybe I'm missing his point entirely :P > > > On Jun 23, 9:02 am, hawkett <[email protected]> wrote: > > > > 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 ortaskqueuesystem? > > > > 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)" <[email protected]> > > > wrote: > > > > > Hi hawkett, > > > > > The bug you found earlier, withTaskQueueaccesses 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 <[email protected]> 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 > > > >taskqueueservices) 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 theTaskQueueAPI 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 theTaskQueueAPI - however the above situation > > > > > means you really have to code explicitly for theTaskQueueAPI, > > > > > 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 ortaskqueuesystem? > > > > > -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)" <[email protected]> > > > > > 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 <[email protected]> wrote: > > > > > > > > Hi Nick, > > > > > > > > In my SDK (just the normal mac download), I can inspect thequeuein > > > > > > > admin console, and have a 'run' and 'delete' button next to > > > > > > > eachtask > > > > > > > in thequeue. When I press 'run', thetaskfires, my server receives > > > > > > > the request, and returns the 302. > > > > > > > > Colin > > > > > > > > On Jun 22, 4:15 pm, "Nick Johnson (Google)" > > > > > > > <[email protected]> > > > > > > > wrote: > > > > > > > > Hi hawkett, > > > > > > > > > In the current release of the SDK, theTaskQueuestub 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 <[email protected]> > > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I'm running into some issues trying to use theTaskQueueAPI > > > > > with > > > > > > > > > restricted access URL's defined in app.yaml - when a URL is > > > > > > > > > defined > > > > > as > > > > > > > > > either 'login: admin' or 'login: required', when thetaskfires > > > > > > > > > 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 ataskperforms 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 thetaskis created. > > > > > > > > > e.g. > > > > > > > > > users.current_user_auth_token() to execute thetaskas the > > > > > > > > > current > > > > > > > > > user. > > > > > > > > > > So I guess the broader question is - where does > > > > > > > > > thetaskqueueget > > > > > 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 [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 -~----------~----~----~----~------~----~------~--~---
