JID naming strategy for a bot army? - ruby-on-rails

I'm planning an XMPP bot system in which a bot is "attached" to a Rails app in background to receive commands and so on. Is is appropriate to use the same account for all apps (40+) and just changed the resource part, like this:
account#host/bot1
account#host/bot2
account#host/bot2
or use totally different JIDs, like:
account1#host
account2#host
account3#host
Pros/cons? Thanks for any feedback!

I'm still learning about this myself, but I've observed that implementing the bots as resources associated with the same bare JID has some characteristics:
XMPP servers may route Message stanzas (but not IQs or Presence stanzas) addressed to one resource to another resource which shares the same JID if delivery fails
The Jabber Session Manager component seems to maintain roster information on the bare JID level, so all the bots will share a XMPP

You want to use unique JIDs, and not reuse same bare JID and change the resource. As Mitch described, sometimes the packet will go to the bare JID, sometimes the full JID. If you're already writing a Robot Army, make a setup script and register the unique names to create the accounts for the Army. It'll test that component as a bonus.
You will drive yourself crazy in 90% of your testing if you just change the resource name.

Related

A few basic questions about Zendesk Support

Zendesk Support is a world-class site full of useful information. But after searching for, and reading, lots of articles I still have some very basic questions:
We run a travel site that takes bookings. We have a need to organise our emails so that everyone can easily find every email regarding an individual booking, both incoming and outgoing. (And later we would add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But throughout the Zendesk site there only seems to be talk of using Support for problems.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to our chosen email address (we will retain and use one of our domain email addresses) and Zendesk Support automatically starts a thread and sends us an email to tell us about the new thread. We then open the Zendesk console, and find the thread.
2) To reply by email to the client we then write a comment in the Zendesk console - is that right?
3) And presumably our email system gets a copy of the comment?
4) What happens to our actual email system? - We will be doing everything in Zendesk, so all the usual maintenance of our email inbox is not being done - marking as read, cancelling stuff, moving to other folders and so on. How do people manage the inbox on the original email server?
Thanks for any help on this.
Zendesk Support is a world-class site full of useful information. But
after searching for, and reading, lots of articles I still have some
very basic questions:
We run a travel site that takes bookings. We have a need to organise
our emails so that everyone can easily find every email regarding an
individual booking, both incoming and outgoing. (And later we would
add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But
throughout the Zendesk site there only seems to be talk of using
Support for problems.
You are correct in that a plurality if not majority of use cases are
for customer contact centers which usually focus on addressing issues
after they arise. At the same time, I know Zendesk is used for a
variety of other use cases including in your space.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to
our chosen email address (we will retain and use one of our domain
email addresses) and Zendesk Support automatically starts a thread and
sends us an email to tell us about the new thread. We then open the
Zendesk console, and find the thread.
Yep, that sounds correct. Details on the mechanism for configuring
the Support Address and redirecting messages to Zendesk can be found
here.
2) To reply by email to the client we then write a comment in the Zendesk > console - is that right?
While it is possible to work from an inbox, Yes, the main emphasis is
on working in the Zendesk agent console.
3) And presumably our email system gets a copy of the comment?
I would suggest to check out some of the articles provided by Zendesk
about email. forwarding, SPF, email archiving
4) What happens to our actual email system? - We will be doing
everything in Zendesk, so all the usual maintenance of our email inbox
is not being done - marking as read, cancelling stuff, moving to other
folders and so on. How do people manage the inbox on the original
email server? Thanks for any help on this.
Basically, Zendesk will be used by agents to respond to communications
and guide the interactions, and the email box can be considered as
operational in directing emails as needed. Separately you can
configure email archiving as linked above.
Depending on what system you're using, Gmail has a built in connector
described here, details on Exchange here, or something else here.
What do you want the interaction to look like between it and Zendesk
and what does your current operation look like compared to motivation
for using something like Zendesk?

Assign rules to sub account in Mandrill

I have a project with an single API key in Mandrill. It has three sub-accounts: production, staging, development. I have created a rule that rejects all requests that don't match a small list of domains and I want to apply that rule to both the staging and development sub accounts. The idea is to not accidentally spam clients while we are testing.
I don't see how I can apply the rule to different sub accounts. Is it possible? If not, and I need to create different APIs for each environment, can someone explain when to use sub-account vs when to create different API keys.
As a bonus, when an email matches a rule, is it possible to reroute it to a specified address instead of rejecting it?
I would use separate sub accounts for tracking different systems in a multi-tenant environment (eg you are acting as a service provider for multiple customers or departments via the same Mandrill account).
In your case, I would definitely use separate API keys for each each environment. The main feature you would potentially want to take advantage of is to be able to set one of those keys (eg staging) as a "test key" such that the emails don't ever get sent, they just get tracked in Mandrill so you can verify that they are working.
The last thing you want to have happen is that emails from your non-production environments actually get sent to real users.
The way I typically do things is to have my development system use a non-test key, but only have dummy users whose email addresses all come back to me so I can test things. Then in my staging system, I use a test key with real users (a copy of the production user database) so that any emails that get sent are captured by Mandrill for verification that they are working, but don't ever get forwarded on to the actual user.
I'm assuming that your rejection rule based on a list of domains is intended to achieve the same result that using a test key does - in which case, go with the test keys and forget the rules.
You can't apply a rule to a specific sub account - only to a specific API key.
And no, you can't reroute an email to a different address based on the outcome of a rule - the best you could so is to wire a webhook to somehow notify your system that the rule was triggered so that your system can re-send the email - but that requires custom development work.
Again, if this is actually just an attempt to avoid sending emails to real users when testing, this is what test keys are for.

Setting up third-party server to interact with Game Center

I'm thinking of adding a feature to my iOS game to allow players to create their own game levels, share them with other players, rate them, etc. There'd be a public repository of user-created levels, sortable by creation date, rating, difficulty, or other criteria.
This kind of functionality would necessitate a third-party server. I was thinking I'd create a RESTful API using Sinatra and run it on Heroku. My question is: what would be the best way to authenticate requests to this API? I would prefer not to require players to create a username and password. I'd like to just use Game Center's ID system.
Any suggestions? I've never done any server-side stuff before so any help is appreciated!
Clarification
Yes, I'm aware that Apple doesn't provide its own system. But it does give developers access to unique Game Center identifiers (developer.apple.com/library/mac/#documentation/…) and I was hoping I could use that somehow to roll my own authentication system without requiring users to sign on via Facebook/Twitter/etc. If that's possible.
Looks like as of iOS 7, this is possible with Game Center using:
[localPlayer generateIdentityVerificationSignatureWithCompletionHandler]
Once you have verified the identity of the player using the generateIdentity call,
Associate the player id with a user on your server's db
Use whatever access token / authentication pattern your REST framework provides for subsequent calls
https://developer.apple.com/library/ios/documentation/GameKit/Reference/GKLocalPlayer_Ref/Reference/Reference.html
Also for reference, here is the dictionary that we end up sending off to our server based on the response from generateIdentityVerificationSignatureWithCompletionHandler
NSDictionary *paramsDict = #{
#"publicKeyUrl":[publicKeyUrl absoluteString],
#"timestamp":[NSString stringWithFormat:#"%llu", timestamp],
#"signature":[signature base64EncodedStringWithOptions:0],
#"salt":[salt base64EncodedStringWithOptions:0],
#"playerID":localPlayer.playerID,
#"bundleID":[[NSBundle mainBundle] bundleIdentifier]
};
edit: as if when I posted this there was no official solution from Apple, but there is now. See the other answers for that, or read on purely for historical / backwards-compatibility interest.
Apple doesn't provide any sort of system for using Apple ID authentication (which includes Game Center) with third-party services. You're on your own for authentication, though you could look into OAuth for allowing single-sign-on via Facebook/Twitter/etc. (Just beware that not everyone has a Facebook/Twitter/etc identity, or one that they want to use for your game.)
In theory, the playerID property on GKPlayer is unique, constant, and not known to anyone else. So, in theory, you could use it for "poor man's authentication": present it to your server, and that's all the server needs to look up and provide player-specific stuff. But this is like authentication by UDID, or by user name only -- the only security it provides is obscurity. And what happens when you have a user who's not signed into Game Center?
Andy's answer is on the right track, but to finish the story: in those docs that he links to, there's an explanation of how to actually authenticate against Apple services that the GameCenter user actually is who he is claiming to be. Link to that part of the docs is below. Basically, the call on the client to generateIdentityVerificationSignatureWithCompletionHandler gives your some data including a URL. You give that data and the URL to your own server, and then from your server you can hit that URL to authenticate the user with the rest of the data that was provided by the call to generateIdentityVerificationSignatureWithCompletionHandler.
https://developer.apple.com/library/ios/documentation/GameKit/Reference/GKLocalPlayer_Ref/index.html#//apple_ref/occ/instm/GKLocalPlayer/generateIdentityVerificationSignatureWithCompletionHandler:
I had a heck of a time figuring this out. I finally used a few hints from this answer, a couple of other SO answers, the php docs and some lucky guessing to come up with this complete answer.
NOTE: This method seems very open to hacking, as anyone could sign whatever they want with their own certificate then pass the server the data, signature and URL to their certificate and get back a "that's a valid GameCenter login" answer so, while this code "works" in the sense that it implements the GC algorithm, the algorithm itself seems flawed. Ideally, we would also check that the certificate came from a trusted source. Extra-paranoia to check that it is Apple's Game Center certificate would be good, too.

Synchronize users between XMPP and django

I'm creating an iOS app which uses django as my backend. I need to have a chat functionality between users.
I heard that XMPP is good for real time communication, and I have successfully set up ejabberd as the XMPP server. But still I'm having hard time to deal with the details:
I created the app first and then the chat feature, so before I setup ejabberd, there are already users in my django DB. I need ejabberd to authenticate users against my existing DB and I have almost solved this by using external authentication. There is only one small problem, as ejabberd seems to require the jabber ID like username#abc.com, and here abc means the virtual host of ejabberd. I don't know maybe I could only use one virtual host on my server(which is the domain name)? But then at the beginning I asked the user to register using emails which are from different domains of course, e.g. gmail.com, yahoo.com, but username#gmail.com#abc.com is not a valid jabber ID, so maybe one small trick I can do here is to convert first # to # and handle it properly in the python script in the backend. But maybe I did it totally wrong?
Another issue is about user profile. I stored the user information as well in my django DB, e.g. display name, avatar url, etc. I learnt that I could use the vCard module if I want to get those information from XMPP server. So maybe I need to have duplicated information in two places? And still I haven't figured out how to synchronize the user information from DB to ejabberd. Or maybe I just need to have only one source, which is my DB, and the iOS client could then query the information from the backend whenever needed?
I feel that XMPP is not easy to setup, is it really popular to use it in your Apps? Especially if chatting is not the main functionality of your App and you are not expecting to have huge messages from big number of users?
You wrote:
but username#gmail.com#abc.com is not a valid jabber ID
You are supposed to escape the user id (i.e "username#gmail").
XEP 106 explains how you should escape the node part of a JID.
In python, it would look something like this:
def escape_node(node):
""" """
node.strip()
node = node.replace('\\', "\\5c")
node = node.replace(' ', "\\20")
node = node.replace('\"', "\\22")
node = node.replace('\&', "\\26")
node = node.replace('\'', "\\27")
node = node.replace('\/', "\\2f")
node = node.replace(':', "\\3a")
node = node.replace('<', "\\3c")
node = node.replace('>', "\\3e")
node = node.replace('#', "\\40")
return node
With regards to storing your users' details in Django. When you register your Django users in XMPP, just make sure that you also register valid vCards for them.
When a Django user changes his details, update the vCard as well.

email service that lets you programmatically create addresses?

I'm considering adding email addresses to a marketing web app. Currently users are able to sign up and get a subdomain address that they can choose (theychoose.domain.com). So I'm thinking of also offering theychoose#domain.com for an email address they can use.
I've pretty much decided on sendgrid.com for sending email through the web interface which takes care of a ton of sending headaches. I'd also like to avoid setting up an email server if I could so I'm looking for services that allow me to set up an account and then programmatically create addresses when a user signs up. I want to find a service that will deal with all the spam filtering etc.
Also, this probably makes no difference but it's a Rails app.
One possibility is to use Google Apps Premier Edition. The API description can be found at http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html.
Keep in mind though, that each user will cost $50/year. However, if you make significantly more than that per registered user, then it may be worth it.

Resources