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:
The application needs permission to send XMPP messages to the user (and the user needs permission to send XMPP messages to the app?), so
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?)
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?
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.)
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.
Related
Very new to the Microsoft ecosystem, trying to understand the flow.
Use-case: we need a Teams bot that sends personal messages to users saying "A customer is waiting at location X" with 2 buttons [Accept] and [Reject] containing personalized links like "https://someurl.com/accept?message=123&user=[user_id]".
How I think I should do it:
Add a special user "servicenotifications#ourdomain.onmicrosoft.com"
Authorize the user & then get a token
Use the token in Send message with cards with cards containing button links
My problem: Got confused with authorizing my special user. Examples on auth V2 require to "redirect the user to the Microsoft identity platform /authorize endpoint." — in a nutshell, show them the login screen, ask for consent and so on.
But my user is a special notification bot, there is no human and I need that fully automated without any user interaction at any point. It's basically a background service sending messages under specific circumstances. Like a Slack bot telling you "Hey, reminder, John has birthday tomorrow".
My questions:
In general, am I moving in the right direction? Or is there a better way for the usecase?
How do I authorize this user without showing any login screen? Because that's an app, a bot, it's not a human and will be controlled fully externally.
Since authentication will be initiated by a bot, the ideal solution is to implement the OAuth2 Client Credentials Flow so that a service principal can be authenticated and authorized. Take a look at Get access without a user for more information.
There may be some operations that may not be allowed for service principals (documented as applications) like Sending chat message to a chat.
I'm trying to change "When replying to a message" (card "Accounts", section "Send mail as") to "Reply from the same address to which the message was sent" in Gmail Settings" by Gmail API (using service account that was delegated domain-wide authority) and I cannot find it in the docs (https://developers.google.com/gmail/api/v1/reference/users/settings/sendAs).
To explain why I want to do this: I'm adding certain role based Google Groups my users are member of to their send email as preferences (by the service account with domain wide authority). For example, users responsible for dealing with legal# address are member of Google Group called legal and they have legal mails in their mailbox. When responsible users change, I just change the membership and new users receive the mails. The problem is that just the first email comes to legal# and reply goes from john.smith# for example. Because of that, I decided to have them reply from legal#, so those who requests something from Legal Departament knows they are communicating with whole Legal Departament and not Mr Smith only. But when Gmail doesn't automatically choose correct address when replying to the legal mail, it doesn't do what I'm trying to do.
It doesn't matter for me if I change it in admin console or by script running on all users. I wasn't able to use any of those ways.
Thank you for your help,
Martin
I'm pretty certain that Gmail setting ("always reply from xx#yy, or reply from the same address to which the message is sent") is not available in the Gmail API. It really is a client-side issue, since the email client chooses the "From:" line when composing each message or reply.
For your issue, you should be able to use Google groups as a collaborative inbox, see: https://support.google.com/a/answer/167430?hl=en
This user note explains your use case, see: https://productforums.google.com/forum/#!topic/apps/siprUn9Nm9g
I'm trying to find information on developing the UX of Facebook notifications being sent from a FB app.
The app will require FB permissions for users to save favorite content within the app (iFrame). We want to remind users to return to the app (once a month) when the public content is updated, but we also want to remind them to return (once a month) when the authorized content is updated.
Is it possible to send email and push notifications for mobile/tablet in these scenarios? Or is it best to only send onsite notifications? Are email/push notifications even possible? I am having a hard time finding information that is clear on the FB Dev. site. Thanks!
All apps developed using developer API can enable notifications. That's why games can send you notifications using your original notification stream.
I would also advise you to only use this communication model, since e-mail from a Facebook app might not be the way Facebook users want their notifications. Also remember that you have to ask for permission to send the user e-mail, and gives the user another argument not to use your FB-app. The less permission you ask for, the more easy it is for users to accept you apps permission request.
Further more, Facebook users can turn off e-mail permission at any given time. Then you would not be able to send e-mails and lose your way of communication to your users.
The scenario is that users of web application can purchase digital items. The web application will use Paypal Instant Payment Notification.
The IPN protocol consists of three steps:
PayPal sends your IPN listener a message that notifies you of the event
Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent.
Let's say it's VERIFIED, how could I know who have completed the transaction or purchased the item (user of the web application) if the user used other email address in his/her paypal? I have stored the email address of the user in session but what if he/she have different paypal email? Paypal email is included in IPN message.
For other details, maybe not useful, the application is written in Struts2 in Google-App-Engine.
You'll need a way to correlate the IPN data coming back with the user. Either by asking them to provide their paypal email or using the username/password generation facility in the IPN service. Here is a somewhat inelegant but functional approach:
When the IPN comes in off the wire, persist the paypal generated username/password and payer_id (in perhaps the datastore).
If you can't correlate by email, then when the user comes back to your site request that they enter the username/password generated from paypal's site once (just to correlate).
Lookup the username/password and then correlate their userid from the UserService back to the payerid.
The reason to use IPN is for subscription services as you can get IPN messages when the subscription is terminated, cancelled, or when payments come in (for an account that stopped paying).
The most important thing to think about is how to correlate a user of your site back to the payer_id (or even payer_ids in some cases) that are used to pay for the services they are using.
On another note, I wouldn't use the session to store information for IPN callbacks, those actually can take a LONG time sometimes (say when the x.com conference is on and everyone is hammering paypal).
If you have a running application or a better description of the look & feel, I might be able to come up with a more elegant suggestion. Let me know if this helps at all.
Why don't you use PayPal's express checkout? This way you negotiate server2server a token and then you can check with PayPal the result of that token on user's return.
If users are buying directly from your application it's easier to implement.
And I think it'is more robust than the method you're using (I never heard of it before :D )
I want to develop a chat application with floowing features
1)user A visits website clinks on
chat .
2)Website picks another user B who
is single(who is not paired) and
pairs him with A.
3)Now A and B can chat till they
want.
Now here neight A or B are registered member of website.Neight they ave any accouunt.
Can i develop such things using jabber/XMPP on appengine ??If yes how??please provide some pointers so that i can start off.
This kind of app is absolutely possible on App Engine, using XMPP, but you won't be able to have them talk directly to eachother, only to your app. You can then "bounce" messages from User A to User B via your bot.
1.) A user visits site, enters their jabber ID (or you could have them log in). You would need to store this JID in the datastore
2.) Another user visits the site, enters JID, and you pick some random existing "single" JID.
3.) Mark both of the JIDs as "connected" and send each a message to start chatting.
4.) At this point, your app can receive messages from the first user, and send them to the second user, and vice versa. This will also help reduce spam and privacy issues, since users won't need to give their actual JID to a stranger.
As for pointers, the App Engine docs are a good place to start, specifically the section on XMPP (Java / Python).