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.
Related
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...
We're trying to implement a Docusign integration for a multi-tenant cloud application (i.e. https://company1.app.com, https://company2.app.com, etc...).
The goal is to allow the tenant admin (our customer) to upload envelopes containing document templates for users to sign when they first login. Each tenant admin will have their own Docusign account/envelopes.
We've implemented a solution for this; however, it requires each tenant admin to create a separate Integration key and go through the process of promoting it to a live account. This is not scalable for us and some of our tenant admins are not tech people, so they have trouble setting this up.
Is there a way to implement the Docusign integration using a single Integration key (our key), but still have tenant admins login with their own Docusign account and upload their own envelopes?
I think you are building a Docusign User Application. You should use the OAuth2 auth flows instead of creating separate Integrator key for each tentant.
A user application is a client that authenticates every end user with DocuSign. These applications are typically web services, mobile applications, or desktop programs that authenticate individual users on the DocuSign platform. Once authenticated, users give consent for the application to display, send, or sign envelopes from their account. For user applications the OAuth2 auth flows are recommended.
A key issue that you may be missing is that your Integration Key works with any account. It is associated with your account just to manage it.
So as CodingDawg says, each of your customers can use your app by logging in with their own user credentials for their own account.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
We want to provide seamless access for all our users to SP's like publishers. The SP's are independent and provide services to a lot of different companies, i.e., we each have independent IdP solutions.
We want it to work as if there were no authentication, i.e., the user find a link on the Internet and follow it. If the site provide special services (that we pay for) for our users we would like them to use our own IdP (but only for our own users) to authenticate them.
Our current SAML setup requires that the SP support IP-address recognition and/or use specific domain names, i.e., the user access a specific domain name or come from our IP-ranges so the SP knows which IdP to redirect to but if our user comes from any other IP-address and don't access a specific URL the system is lost.
How is this solved?
I think a cookie given by the SP every time the user gets authenticated (from our network which the SP recognizes) can solve this but is that the standard? And it is not really a solution as it requires that our users have visited them at least once from our network!
This isn't so much a SAML question as it is an identity provider discovery problem which isn't specific to the protocol. How is a publisher supposed to know / decide that a particular user should be redirected to your IdP via SAML or any other protocol? This isn't a tractable problem in a general sense. The publisher and you will need to agree on a contract between two entities (you and these publishers) when it comes to these special users / services.
One possible implementation of IdP discovery that doesn't involve domains or IP ranges is a dynamic lookup of the IdP based on the user's identity. User clicks a link, navigates to the publisher site and attempts to login with (for example) his identity of myname#mycompany.com . The publisher can then do a lookup of mycompany.com in their identity store of special users / services / IdPs and determine that this user should not be allowed to login with local (publisher-managed) credentials. Instead, the user should be sent to some 3rd party IdP via a SAML authentication request. The publisher can do this at the time of user login but before the user has a chance to enter their publisher-managed credentials, be it via your favorite AJAX technique or some other form of UI gratification.
The publisher could use a persistent cookie so that the next time this user comes to this publisher they'll know that this user "belongs" to a 3rd party IdP and redirect accordingly.
I am asked by my company to do a Proof-Of-Concept for our document management using Box. We have an enterprise account.
What I did is I added an app in my account - to get my api keys ("client_id" and "client_secret").
Then after this Using the Box Api for .net4.0, I manage to connect my MVC app with our box account using OAuth2.
I can now view files and folders as well as uploading files.
Now my problem is I need to restrict the files that can be viewed by the user logged.
I noticed that when changing the email that is use to log-in (we're using SSO)
The user info doesn't change.
I am using GetCurrentUserInformationAsync() method of the BoxApi V2.
Is it possible to perform user management using API?
(P.S. I am not the admin of our enterprise account)
Thanks
To change the email, you will be require the admin rights. First you need to create the email alias for that account and then you can replace the primary email address with your alias.