How to send a message to a client using WampSharp? - wampsharp

Is it possible to do this way:
WampSharp client app connects to a WampSharp Server, then this server sends message/call client's function?

The client can subscribe to a topic and then you can publish to this topic, specifying in the publish options' eligible property the session id of the client.
For functions this is more tricky - you would need to register the procedure with a unique name which depends on the client's session id and then call it from the server side.

Related

Websocket from UI connecting to one of the instances for Spring boot application for streaming the data coming on a queue

I have an UI application (displays streaming) which makes a WebSocket connection to the Spring Boot microservice (multiple JVM'S) and this service forwards the request to one of the upstream servers and listens to the responses on a JMS queue coming from upstream server, which then response messages had to be returned to the socket.
Issue we are facing is since the socket is point to point, and the Spring Boot application is running on multiple instances which all are listening to the same JMS queue we are unable to serve the data back to the WebSocket when a message is received on a instance which the request to upstream wasn't made.
Here's the basic flow:
WebSocket -> instance1, instance2, instance3 -> Data provider
Instance1 made the request to data provider.
Data provider sends the data back to the queue
Instance 3 receives the message, but it doesn't have the socket connection to send the data back.
We had an interim solution using correlation id in JMS headers and selectors on the queue however now the data publisher is not able to provide the correlation id to depend on.
Does anybody have a better suggestion to address this?
Since you're using a request/reply pattern with JMS you must either use a correlation ID or a unique temporary queue for the response.
You indicated that, "the data publisher is not able to provide the correlation id to depend on." However, your application actually provides the correlation ID. The "data provider" in this case just needs to take it from the message it receives and put it into the response message. The process only requires 2 method calls by the "data provider" - javax.jms.Message.getJMSCorrelationID and javax.jms.Message.setJMSCorrelationID.
If the "data provider" can't do this then it's doubtful they will be able to accomplish the other option of using a unique temporary queue for the response. However, it's worth explaining in any case. When one of your "instance" servers sends the request message it first needs to use javax.jms.Session.createTemporaryQueue to create a temporary queue and then take the return parameter of that method and set it on the request message using javax.jms.Message.setJMSReplyTo. When the "data provider" receives the message they will get this value using javax.jms.Message.getJMSReplyTo and then send the response to this queue where the "instance" will then retrieve it.
These are the two generally accepted ways to implement a request/response pattern with JMS. I don't know of any other ways to implement such a pattern.

how to send message to a specific user by username at any application point

I am implementing spring boot stomp message broker socket to interact with webclient. i need to send sms to a specific user by username at some application point,means the message will be trigger from server to client. client will subscribe to a topic/queue. i heard #SendtoUser send sms to the perticular user, but here in my case user is just subscribing a topic, then from backend i need to send sms time to time to specific user. user will not send any sms to server.
its just push based sms.
messagingTemplate.convertAndSendToUser(sessionId,"/queue/something", payload,
headerAccessor.getMessageHeaders());
but here from where will i get the session id for the targeted user. here user is just subscribing the topic once.
You can find answer to a similar question (with project exemple) here :
Spring websocket send to specific people
The fact that user is subscribing once is not a problem. One the connection is established, the server can send has much message as needed.

Same login on two different Laravel projects on same server

I want to create two portals on same server and diferent subdomain:
app1.domain.com
app2.domain.com
I want to separate in two different laravel projects, when it is authenticated in one of the portals in the other portal should be authenticated.
How can i do that? Any suggestions would be very helpful
I think you are looking for SSO
For Laravel in my quick search found some Packages
jasny/sso is one of them, explained as :
How it works
When using SSO, when can distinguish 3 parties:
Client - This is the browser of the visitor
Broker - The website which is visited
Server - The place that holds the user info and credentials
The broker has an id and a secret. These are know to both the broker and server.
When the client visits the broker, it creates a random token, which is stored in a cookie. The broker will then send the client to the server, passing along the broker's id and token. The server creates a hash using the broker id, broker secret and the token. This hash is used to create a link to the users session. When the link is created the server redirects the client back to the broker.
The broker can create the same link hash using the token (from the cookie), the broker id and the broker secret. When doing requests, it passes that has as session id.
The server will notice that the session id is a link and use the linked session. As such, the broker and client are using the same session. When another broker joins in, it will also use the same session.
HTH!

How to get MQTT client id in Websphere AS?

My application receives MQTT messages via JMS on a Websphere AS. The MQTT endpoint is a Websphere MQ.
Is there any way to identify the sender of the message (the sending device, not Websphere MQ ;-) )? I could not find a matching field in the jms message header...
When creating the MQTT channel there are options to use either the MQTT Client ID or the Username for authorization checks. If the channel is configured to use JAAS and the option to use the Username is selected, I believe the MQMD.UserID inherits the Username. I don't have JAAS authentication configured but when I get some time later I'll test it and update.
I was able to test the option that uses the ClientID for authorization and it does not result in the client ID ending up in the MQMD.UserID field.
Since identity propagation is a common requirement, I'd suggest raising a Request For Enhancement (RFE) stating that either Client ID or Username should propagate to the MQMD.UserID, depending onthe channel setting.

JMS / MQ confidentiality between clients

I'm designing a system where one server must send messages to lots of independent clients. The clients doesn't know about each other and should not be able to consume, peek or in any other way acquire knowledge about each others messages.
I therefore wonder if JMS / ActiveMq have the ability to control which clients get which messages?
I want all the clients to connect to the same JSM provider (the 'destination') and consume only messages meant for them. This would be a simple setup from the servers point of view.
An alternative would be to acquire webservice endpoints from all the clients and perform ws-calls every time the server have a message for a client. I think this alternative sound 'wrong' as I think ws calls are bloated. There is a great overhead for each ws call, and this server would have to make 1000's of call each day. In my opinion this would be suboptimal for the server...
Short answer: Use Message selector.
Detail answer:
The question doesn't mention about how conversation is initiated. So here my answers for both scenarios.
a) If client initiates the conversation (i.e. Client sends a message to server and waiting for a reply).
This is a request/reply scenario. Messaging/JMS is a decoupled communication system. But request/reply is a common pattern in JMS. It can be implemented using correlation pattern.
A unique identifier(correlation id) is sent part of the request message.
Server receives the message and sets the correlation id in the reply message.
Client uses Message selector to receive the message with the correct correlation id.
b) If server initiates the conversation (i.e. Server sends messages to the clients without client request).
In this case, similar approach can be used.
A fixed client id is assigned to each client.
Server maintains all client ids and sets client id of the recipient as correlation id of the message.
Client uses Message selector to receive the message which has correlation id equals to its client id.
Update about confidentiality.
Following info extracted from this link useful for you to understand JMS security.
JMS does not specify a security
contract or an API for controlling
message confidentiality and integrity.
Security is considered to be a
JMS-provider-specific feature. It is
controlled by a System Administrator
rather than implemented
programmatically or by the J2EE server
runtime.
Two major features of JMS security are Authentication and Authorization. According to my knowledge, JMS security for client access is focusing on protecting the JMS destinations (not the individual messages). As long as a client has access to a destination, the security role assigned to the client is applicable for all the messages belongs to the destination.
Based on this,
Solution 1: If the client code is controlled by a trusted party.
Follow my solutions in my original answer.
This will make sure the message is delivered to the right person. But will not protect anything if the client code is purposely modified to receive all messages.
Solution 2: Assign private destination and user account to each client and configure security such that user account of a client can access only its destination.
Note: Found a link about "Restrictions for message selectors to provide message level authorization". But I think it is a vendor specific custom feature.
Hope this will be helpful.

Resources