views:

301

answers:

2

I've read this paragraph from the App Engine documentation a dozen times and still am completely in the dark about how chat invitations work:

Invitations

Google Talk and other chat servers will only accept messages for users that are "subscribed" to the sender, either because the user invited the sender to chat or because the user accepted an invitation to chat sent by the sender. An App Engine app can send chat invitations using the service API. As with sending email, a best practice is to send a chat invitation only when the user asks, such as by clicking a button on a web page. Alternatively, the app can ask the user to send an invitation to the app's XMPP address to enable receiving of messages.

App Engine accepts all chat invitations automatically, and does not communicate invitations to the application. App Engine will route all chat messages to the application, regardless of whether the sender previously sent an invitation to the app.

Maybe the problem is I haven't used chat so I'm not familiar with how invitations work in practice. But the first issue is how/why/whether an application needs/gets permission to chat with a user.

The paragraph above seems to say the following:

  1. The application needs permission to send XMPP messages to the user (and the user needs permission to send XMPP messages to the app?), so
  2. The user has to send an invitation to the app to allow it to send messages to the user (and the app has to send an invitation to the user to allow the user to send messages to the app?)
  3. App Engine receives the chat invitation but does not communicate it to the app

Question: How does the app know whether it's ok to send messages to the user since App Engine does communicate anything to app about the user's response to the invitation?

+1  A: 

Gmail is a great example:

I send a message to my friend who is not on my "Friend List". Gmail does not deliver my message, but instead delivers a message that says "Anthony would like to chat. Do you accept?"

If my friend clicks "yes", they get my message and I'm on their friend list and they are on my friend list, and we can chat freely without Gmail making sure it's okay.

If my friend clicks "no", they never see my original message and GMail asks permission if I try again later.

So the App does communicate with the user on the other end, it just doesn't relay the message, only that I'm interested in being chat-buddies.

quick update

Another way of looking at this (if you remember these days), is a collect call. The operator simply says "Do you wish to accept a collect call from Jones?" The operator doesn't say "He says it's really important, he's in jail." And the operator doesn't say "He said no, you can rot in jail." to Jones. They broker the connection without either party making real contact until both parties agree.

(Of course, we would always say our name was "I'm stuck at the mall!" when we tried calling home collect. But since there is no charge for a chat, such sneaky workarounds are not necessary in the XMPP world.)

Anthony
@Anthony: Gmail is a good example. That was very helpful, thanks. But I'm still stuck on this issue: "App Engine will route all chat messages to the application, regardless of whether the sender previously sent an invitation to the app." Doesn't that mean that if a user knows the XMPP address of the application, s/he can send IMs to the application without authorization?
Egg Yolk
I think you've got the idea. To be honest, I've never used XMPP for an application, so I'm still imagining that the application as a go-between for two users. But based on the parts you're highlighting, it would seem that it boils down to "anybody can send IM's to an application without any invitation." I think the entire point of the paragraph is to emphasize the difference between "users" and "apps" and that by default, apps are non-restrictive users...
Anthony
But the other thing to consider is that apps can request invitations to be sent. This makes it sound like apps still must respect the restrictiveness of users. So this means if an app wants to send IM's, it either needs to send an invitation or be sent one by the user who wants IM's from the app. But users can send IMs to the apps without any invitation at all. Are you worried about a QoS attack, or just what the app does with IM's sent to it?
Anthony
So you can make an app that sends your users an IM that says "your stock has gone up 2 points", but the user has to invite the app in some way first. But if you maybe wanted to have your app send stock quotes to non-subscribers, anyone could send the XMPP address the stock symbol and get a response of the current price, etc. The app would then request an invitation if one hasn't been set up by the user, and once the user accepts, it gets the response of the quote.
Anthony
To wrap up (I think)...If the app sends a user a message and the user has not accepted an invitation, I'm pretty certain that the user gets an invitation right then. So if the question is "how does the app know if it is authorized to send to a user?" It doesn't need to. If it isn't invited, an invitation is sent ahead of the message. How do you prevent unauthorized users from sending messages? You can't, but you can refuse to respond based on your own code for how to to handle incoming IM's (just like handling SPAM, etc.)
Anthony
@egg - if I know your appid, I can send you an XMPP message without being invited, and your app can reply. If you want to control who has access to your service, you'll have to check the user ID in your app and handle security yourself. On the other hand, your app *cannot* send arbitrary XMPP messages to users if they haven't (1) accepted your invitation, or (2) sent you a message previously.
mb
+1  A: 

Use the get_presence() function to determine if it's ok to send to the user. If you send a message to a user that has not accepted an invitation, most XMPP servers (including Google Talk) will not deliver either the message or an automatic invitation. With Google Talk at least, a user who has accepted an invitation will be "present" even when they're logged off, since Gmail can deliver your XMPP messages as pseudo-emails.

Wooble