Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a REST API which receives some information (let's say events) from clients. Now I need to send some information from the server to clients. I'm trying to add MQTT as an additional way for clients to communicate with the server. Unlike HTTP MQTT allows me to do both: sending and receiving, so it's possible to make MQTT analogs for all existing REST API methods.
Receive events from clients - HTTP, MQTT
Sent commands to clients - MQTT
My idea was to make a "listener" which subscribes to all "event" MQTT topics and translate them into HTTP requests to the REST API (to keep components decoupled). But there is a problem: this listener is a simple client. It doesn't have any special permissions and can't get publisher's credentials to act on his behalf when talking with the REST API. MQTT doesn't even allow a subscriber to get who published a particular message.
One solution is to use MQTT only for sending information from the server to clients and keep using REST API for all incoming requests. But that looks strange :)
Another way is to use broker custom hooks but not all brokers support it and it's not a part of the MQTT specification so it's not very reliable.
Any ideas how to organize it in a proper way?
Given that most (if not all) MQTT brokers support wildcard topics in ACLs you can encode the user in the topic and then grant the agent access to the wild card topic that matches all users.
e.g.
publish to events/<user>
and then grant the agent access to the topic events/+
You can then make sure that the Users ACL makes sure only they can publish to events/<user> such ensuring that users can not impersonate each other.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I want to set up 3 microservice architecture; one would be a frontend, the second one would be a backend, and the third one would be a pod that would be responsible for running some commands. The frontend should enable a user to run a sequence of commands and show their outputs in real-time, these commands would get passed to the backend that would then create a pod to actually run the commands. So basically, as the commands run in a pod, the frontend should be able to display the output from these commands in real-time.
I have tried researching on the solution and I came across Pusher, but I want to build something myself instead of using some 3rd party apps. Also, I know there are many technologies available out there, like WebSockets, which would be the best technology to use in this case?
(This answer is assuming you're interested in using Kubernetes since this question is tagged with kubernetes and you mentioned Pods).
It sounds like you have the basic building blocks assembled already, and you just need a way to stream the logs through the backend, and expose them in a way the frontend can subscribe to.
You're on the right track with WebSockets, that tends to be the easiest way to stream data from an API into your frontend. One way to connect these pieces is to have the backend use the Kubernetes API to create a Job pod whose logs can be streamed. The workflow could go as follows:
frontend makes a request to the backend to run a command via WebSocket
backend waits for the frontend to send the command over the WebSocket
once received, the backend uses the Kubernetes Job API to create a Job pod
if the Job was successfully created, the backend opens a WebSocket via the Watch/GetLogs API, and pipes anything written to that pod's logs back into the WebSocket with the frontend.
It's up to you to decide the format of data returned over the WebSocket (e.g., plaintext, JSON, etc.).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
How can I protect my REST API to identify fake request generated by some user / script and flooding my server with millions of requests?
If some one wrote any script or program and generate millions of calls to my REST API how can I protect my service from these request so that my API wont goes down. One way is I can use captcha but captcha is useful when caller is human. If caller is an application I can not use captcha. Is there any frameworks available for the same to handle such scenarios?
What your service is experiencing is called a DoS / DDoS attack. This is currently one of the most common attacks on web services.
There are many ways to mitigate such attack all
boiling down to separating the legit requests made by your API consumers from the malicious ones performed by the attacker/attackers. Such attacks are usually automatized and therefore the requests resemble one another in some way (IP range, HTTP headers, etc.). For example a very simple approach would be to identify the IP range that the attack comes from and block it out on your service's firewall.
There are a few posts here that discuss prevention of (D)DoS, e.g. How do major sites prevent DDoS? or What techniques do advanced firewalls use to protect againt DoS/DDoS?.
Third party services/products might help you protect your API. I don't want to mention any here as I don't want to advertise any of them. You'll need to do some searching.
Good luck.
You can pass a token for each request.
This token should be use any encryption algorithm and use a secret key to encrypt and decrypt token in both client and REST service.
Ex :
Client request : What is the weather of Chennai ? Token : chennai + 123 (Key)
Server Response : chennai123 : its valid : response 40 !!
Here key is 123 it should not available in public
Building an instant chat app (native IOS and web). Exploring whether to use XMPP or MQTT as application protocols. Seemingly I can't have users editing old messages on XMPP. Can messages be edited on MQTT?
Example: I want to implement "Edit Message" like Slack offers, but upon clicking "(edited)" to allow the user to see the different versions of the message and their timestamps (like the edit history for comments you find in Facebook), enabling an "audit trail" of the conversation.
Follow-up: As it seems this can only be achieved through a "hack", would it be better to get the hack done on XMPP or MQTT or some other protocol/websockets/JSON, etc?
Once a MQTT message is published to the broker the publishing client has no more control over that message at all.
Most brokers will not allow you to edit the message either as they will just forward the message instantly to all clients subscribed to the relevant topics and queue the message for any offline clients with persistent subscriptions.
The only exception may be the mosca broker that has a call back for when messages reach the broker, but this would not allow a user to edit a message, only the system to possibly update the payload in the instant before it was forwarded to the subscribed clients.
Hardlib's advice is correct, editing messages in this way is not supported by most MQTT implementations and to implement it would break the loose coupling between publisher and subscriber that is the virtue of MQTT. In other words this should be implemented at a higher level or through other means.
That said, if I understand editing to mean the ability to change what the broker forwards to clients that were not online during the initial publication, you could implement this with retained messages. Consider this:
Client A is subscribed to topic clientb/# and Client B is subscribed to topic clienta/#.
Client A publishes a message to clienta/(unique message id) while Client B is not actively connected. The broker retains the message.
Client A decides to edit the message so (through some interface you devise) they publish an amended message to clienta/(unique message id) which replaces the message and, from a subscribers perspective, edits what is there.
Client B receives the amended message when they come online and (as long as there isn't a persistent session or something like that) has no knowledge of the change.
From this example you can probably tell why this is a bad idea as the server would retain every single message in a different topic and would likely need regular pruning... not mention that it would make a mess out of timestamps and require all sorts of other work arounds. However, if there is some reason that you have to implement it this way you could hack something usable together.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently I have a server-side user list that is pulled down by a User A's browser and then tracks locally the state of the system via pusher as users log on or off.
As User A's status changes, it sends ajax updates to the server to notify its status.
I am having de-sync issues with the status of users that are pulled down from the database vs the local tracking of the state in the browser while it is keeping track of users on the channel.
I would like to create a server-side observer that is constantly monitoring the pusher channels and acts as redundant method to sync the clients browser to the database.
Can anyone point me in the right direction of a good solution to use for the following necessary functions:
-Needs to integrate with pusher and be able to listen to/respond to events, not just send json messages over the channel
-Needs to receive all events that are published on a channel
I am unsure what libraries or solutions exist that can listen to Pusher channel events on the server.
Any suggestions would be much appreciated.
The best solution for this is to use Pusher's WebHooks. The benefit of this is that you can receive a number of events related to user activity and all events will be delivered i.e. failures are queued and resent.
There are no language requirements to consuming WebHooks as it's just an HTTP request made from Pusher to an endpoint that you define.
Right now you can receive channel vacated and occupied events (if a channel has any subscribers or none) and presence events (users joining and leaving a channel). It's likely that Pusher will expose additional events as WebHooks in the future.
If you were to run a daemon process which connects as a client there is the possibility of missing events during times where the client isn't connected e.g. network downtime or reconnection phases.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I read somewhere a while ago that one can configure external jabber components (XEP-0114) to send XMPP stanza's on behalf on any user. For instance say i have a component bind to (component.localhost) and i want it to send a message stanza with "from" attribute set to "user#localhost".
I am trying to achieve this with ejabberd. Won't be surprised if I will have to hack down ejabberd src to get this working (if at all possible).
If you are using ejabberd, you can use the {service_check_from, false} option in your service definition to disable the verification on the "from" attribute.
Keep in mind, though, that XEP 0114 requires that the "host" part of the JIDs match the name of the component.
See the corresponding section of ejabberd documentation for all the gory details.
Technically, you have to actually write the component, but this can easily be done.
You have first to confugre ejabberd so that it accepts connections on a specific for your component, with a given componet JID and a password. The default configuration file has several examples, for gateways for example.
Once this is done, connect an XMPP library/client with this component's credential and you should be good to go! The only constraint is that you send valid XML.
Your component will typically only be allowed to send stanzas appearing to be from *#component.domain.com, rather than #.domain.com. This is a security feature.
If you want this functionality, you may have to write a server plugin rather than an external component.