a customer wants enable a chat/instant messenger for his application webside. He is using Lync Server internally to Chat in-house. Now, he requires the following:
A external user (which will not be an AD user) logs into the webside is able to chat with a person inside the company. The internal user will receive those messages via his lync client.
What's the best way to achieve this?
i thought about bot that delegates messages from the webside to the lync server that does the rest. But how can i send a message as an external user?
The usual way to approach this is with the following components:
A bot that connects to the internal Lync infrastructure as an ApplicationEndpoint, and manages conversations with external/internal users
A Web or WCF service that exposes methods over http to external users - this could be built into the bot, or could be a separate service that communicates with the bot in some way
The web UI for presenting a users presence, allowing click-to-call, initiating and displaying a conversation etc
As an example, the WCF service could expose a few methods:
GetPresence(targetSipUri) - returns a presence value for the given uri
SendIM(targetSipUri, message) - sends an IM to the given uri
GetReplies() - polls for any responses
When you get into the detail you might need more methods - e.g. it may be an idea to generate a conversation token and pass this around
The web UI could present a list of contacts with a presence status (GetPresence), then allow the user to click a presence contact to initiate a new conversation window and send the inital message (SendIM), then poll the service for any replies from the contact (GetReplies) - note, the bot will have to queue replies internally until GetReplies is called.
There are commercial products that might meet your needs - a quick search for Lync webchat should turn up a few. Also, it may be worth looking into the Lync Web App, to see if this works for your customer
Edit: In answer to the comment below - yes, your internal users will see a conversation from "Our Lync Bot". If you don't know who your users are (e.g. random potential customers browsing a shopping site), you can grab some info from them (name, product to discuss etc) and have the bot display this to the internal user, either as part of the IM conversation, or as conversation context displayed in a Conversation Window Extension.
If your external users are known in advance (e.g. registered customers), and the internal user MUST see the conversation as being from them, then you will need to create a UserEndpoint for each conversation - but this would rely on having the user in AD.
Related
I am working on setting up a few new bots for Hangouts Chat. Part of the effort involves using Hubot, which is working well. Another use case requires posting to user spaces based on external functions, which is done via a python command script. I have a project and separate service account setup for each bot, and the permissions for the bot service account appear to be the same. None of the bots have corresponding domain-wide delegation at the GSuite Security level.
We obtain the spaceid for each user via one Hubot that saves their spaceid to a database, and the python script can then lookup the user and obtain that id.
However, only one of the 5 projects appears to be able to post a message to a user space. All others get a 403 error and fail to post. The same python script is used for any of the 'bots' with the only difference being the json file used for authentication.
Not sure this is enough information. But, I wonder what could be causing this problem if not permissions?
I figured it out. The spaceid I was registering via another bot is not the same as the spaceid associated with the bot/user communication for any other bot. In other words, it appears that the spaceid a bot sees for a user is unique to its communication with the user. I will need to have users register with the bot that needs to send the message instead of a common registration bot
We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2
types:
Block in one way. You are blocked, but you can write to
blocked user.
Block in two ways. You are blocked and you also can't
write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)
XMPP Clients
XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.
XMPP Servers
XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.
Help:see this link
If we are talking about XMPP protocol - there is an ability to block any communications from/to (see example 48)
So, by default, you can set it for each user for example.
Then, if we need to allow to communicate with someone specific,
then you can add this user to your privacy list with action=allow and order greater than 'full block'. Here is actually a good example of whitelist implementation via Privacy Lists, see example 8:
and (3) 'special', which allows communications only with three
specific entities.
Currently I am using Olark for live chat on my website.
I am planning to replace it with an in house OpenFire installation.
However, there is one problem.
With Olark live chat snippet (which I embed on my website) - if a user opens the website in multiple tabs - it's prefilled with the ongoing conversation. For e.g. - you can try it on (moonclerk.com).
How do I achieve the same pre population of chat window with the ongoing conversation with OpenFire + FP WebChat?
The way we achieve it at Olark is not exactly trivial. We don't actually use an XMPP client on the end-user's side, which makes it a bit easier, but basically our transport layer is able to grab conversation events for a conversation in-progress based on a session UUID that is stored in the user's cookies. XMPP isn't involved in that process at all, for us (it is only concerned with final delivery to and from Operators).
I don't know what FastPath's architecture is like, but if you were looking for this functionality, or to add it yourself, XMPP supports retrieving some n number of messages from the message history for a client. Check out XMPPFramework - Retrieve Archived Messages From Openfire Server for more on that.
I just started working on xmpp its wiki page says that "The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server."Hence it is decentralized
In my application I want that user can create a specific group chat box on a click of button.
My question is if the main user who created chatbox become offline will the chat box created by him will remain alive as decentralized suggest that user who created will act as a server. If not , could anyone suggest what can be done for keeping chatboxes alive even when the user become offline.
Multi User Chats (called 'MUC' in the XMPP world) are hosted by a XMPP component. This means that the user who initiated the chat *does not act as chat provider, but this particular MUC component. This component runs usually on the same machine as your XMPP server. Therefore the chat exists - if the MUC is marked as permanent - even if the user quits the chat.
More information can be found in XEP-0045: Multi-User Chat
I want to integrate my web application with chat and notification service and the foremost and the best, i understand is XMPP. After going through the nitty gritties, though i understood most of it but I got stuck here i.e. how will i run a Chat and notification service together.
One option is to have run different connections of Strophe, long polling with different accounts one for chat and other for notifications.
Other one is to have both notifications and chat on the same accounts but now the problem if the user signs out from chat he wont be able to receive notifications.
The first option does not seem feasible to me, but is there a way the later one could work?
Use one connection, to your "chat" service. Run your notification service as a component on your chat server, or run a separate server and federate them together. The client will be able to contact the notification service (and vice-versa) via the naming scheme in the Jabber ID's (JIDs) that you pick. Make sure you pick a different domain name for the user accounts on the chat side than for the notification service.