Ejabberd newbie here. I hope this question makes sense.
We had a need to setup our own XMPP server so that customers on web and a Bria client can utilize it. I was able to get the basics up and running using ejabberd.
All users will be in the 'xmpp.exampledomain.com'
We also have a custom SMS gateway we built (which is really a server which can accept json APIs).
So what I am trying to accomplish:
Our platform would create a 'normal' xmpp user so the user can login to ejabberd.
This user can add roster contacts of other 'normal' xmpp users.
If this user wants to send messages via SMS, we would instruct them to add roster contacts (i assume) with the format 12125551234#sms.exampledomain.com. (adding the contact works currently)
If a user sends a message to this "SMS" contact, have ejabberd call our custom SMS gateway via a json API instead of attempting to deliver via normal xmpp.
Is this even possible?
For inbound from the SMS Gateway server, can call the ejabberd API send message function, so inbound is fairly easy.
I appreciate any suggestions
thanks
What you want was called a "transport" in the old days of IRC, ICQ, AIM and MSN. They were programs that you installed next to ejabberd (or other Jabber servers). Example usage:
you download a transport for ICQ
configure it to have access to ICQ,
and then configure ejabberd to connect to that transport, and allow users to contact it at address icq.example.com.
There are very old tutorials for your curiosity:
https://www.ejabberd.im/tutorials-transports/index.html
I don't know if the old "SMS-Jabber transports" will work nowadays. Searching revelaed few results:
https://www.jethrocarr.com/2013/06/03/smstoxmpp/
https://sourceforge.net/projects/jabbersms/
https://www.jabber.cz/wiki/SMS_transport
Alternatively, as you mentioned you already have a SMS program, if you can get your hands on Erlang or Elixir, you can write an ejabberd module that registers at sms.example.com, and forwards XMPP messages as json API...
Related
I need advice after looking a lot about receive push/toast notifications regardless of the status of the application (closed or open).
The application communicates with a NodeJS API.
The idea is that a user logs in once to the application and then can receive notifications (depending on his account): i the user restarts his system for example, at startup he receives notifications without having to open the application (like the Mail application for example).
Most tutorials on MSDN use Azure and I don' use this. I would like to know if you have tips or links (tutorials, ...) for doing this in an UWP (or WinRT) application.
Thanks in advance for your help.
Regards
You can send push notifications from your NodeJS api via Windows Notification Service. This service has nothing to do with azure but when using Azure Notifications Hub it will be easier to get it implemented, but again this is not required;
In essence:
- register your app in dev center
- obtain a client id and client secret to use WNS in the dev center
- When your app launch it obtains a push notification channel uri and sends this to your backend. Your backend need to save all the URI's for the different devices
- When you have a notification select the uri's of the devices you want to send the push notification to
- post a xml message (based on what you want to update, tile, toast, badge or raw) to the URI's. To be able to post you need to authenticatie with the client id and client secret
more detailed read: https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview#
Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.
how to register an user using converse.js to ejabberd from javascript instead of using register form of converse.js. I want to register the user using converse.js api instead doing it manually from the form. Please help me with your suggestions.
Converse.js supports XMPP-0077 in band registrations to allow users to manually register new accounts for themselves.
It should be possible to also do the same thing automatically/programmatically instead of expecting the user to do it.
However, you would need to write new code to do this.
Instead of letting the user specify their username and password, you would generate and then send those values to the XMPP server automatically with Javascript.
However, a better and more secure way would most likely be to do this server-side. Either by using a RESTful API provided by the XMPP server (some do, but not all), or by creating a server-side XMPP client which does the registration.
I am creating ejabberd xmpp client for charting similar to WhatsApp. Want to understand, how does WhatsApp sync contacts with server? How does WhatsApp find out all registered users with server and synchronise it with your address book?
This feature is not related to XMPP or ejabberd. If you want to detect contact of your user you need to implement that feature in a custom way.
You need to upload an anonymised version of the user address book with hash of phone number and email and store that on your server.
When another user with a phone number or email address matching that hashes join the service you can find who knows it and do operations to notify each parties that they are both using the service (and/or add them in roster for example).
So, this is a purely custom extension to ejabberd you will have to implement.
We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account