Hi Nick. Thanks for the reply. It does clear up the choice of architecture :) My use case is similar to a web-based chat, where x clients written in JavaScript receive updates from the App Engine server using XMPP over BOSH or similar Comet mechanism. And yes, I can of course use existing Comet implementations, but I saw it as a nice way to use XMPP.
Cheers; PS On Tue, Sep 8, 2009 at 12:28 PM, Nick Johnson (Google) < [email protected]> wrote: > Hi Peter, > > On Tue, Sep 8, 2009 at 11:20 AM, Peter Svensson <[email protected]>wrote: > >> I've been toying around with using Ajax to send XMPP requests to an App >> Engine instance of mine, and this works (in principle, the packets get >> there, but I have other problems, for other mails) as long as I am logged in >> as the administrator of the app engine instance. Seriously. What is the >> reason for this? >> >> When I try to send an Ajax request from my page (which is loaded from >> /static from the very same app engine project, I get a 302 back, trying to >> redirect my JavaScript logic to a login page. OK, even if I were to act on >> that and later on detect that the user is logged in, why must the user be an >> administrator? According to the docs; >> >> ------- >> >> To handle incoming messages, you simply create a request handler that >> accepts POST requests at this URL path. >> >> This URL path is restricted to app administrators automatically. The XMPP >> service connects to the app with "administrator" status for the purposes of >> accessing this URL path. You can configure the path to have this restriction >> explicitly if you like, but this is not necessary. Only the XMPP service and >> clients authenticated as administrators using Google Accounts can access >> this URL path. >> >> -------- >> >> >> This effectively makes app engine completely useless if you're going to >> (like me) build a hand-written client which will utilize XMPP for updates >> (between clients), and not just writing a bot for gchat. I don't mean that >> writing a bot for gchat is not interesting as such, but this login thing >> really seems very restrictive. >> > > I think you're misunderstanding the intent of the XMPP URLs. They're > intended to be accessed by the App Engine XMPP subsystem, not by your users > directly over HTTP. If you're simply posting to your app from a web-based > client, why are you using the XMPP URLs at all? Why not just post to a URL > you control, and handle those requests separately from incoming XMPP > requests? > > >> I can understand that Google want control over its resources so that >> someone doesn't write a completely open thing that lead to an >> overutilization of the current XMPP infrastructure. But first of all I don't >> see how that could not be solved by just charging more dollars of the >> controlling app engine project (which will happen automatically anyway), and >> secondly if authentication of XMPP clients really is needed, just let anyone >> login in who has a Google account. >> >> >> Thanks! >> >> >> Cheers, >> PS >> >> >> > > > -- > Nick Johnson, Developer Programs Engineer, App Engine > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
