In a c++ quickfix server app, is there a way to call sendToTarget when the target session is not logged on, so that when the client possibly does logon later it will get all the messages that were "sent" since the its logon?
By default, QuickFIX will store all outgoing messages in case they are requested later by the client. If the client detects a gap in the incoming sequence numbers they will request a message resend. If you send a message when the client is not connected it will be stored and the client will request a Resend at the next logon.
Related
I have a high level architecture question:
I have a django app where users can send out sms to their contacts (telephone numbers, not users of my app). I am trying to implement a system where if someone replies to a specific text, such reply is forwarded to the user that started the thread.
I implemented an inbound webhooks to receive sms but I am now facing a problem: how do I know which text is a reply replying to? I can't seem to find any type of id in the sms inbound request and I am now starting to fear that this is just impossible.
Any idea? Should I try to use "Conversations"? Would that solve my problem and if so, how should I go about it?
Any suggestion?
Twilio developer evangelist here.
You cannot get the message that a user is replying to, because that doesn't exist in SMS. SMS messages are simply chronological. To test for yourself, open your SMS app and try to reply to the second to last message from someone.
You have a few options to try to tie a reply to a specific message:
Only ever send one message to be replied to at a time. Once you receive a reply to one message (or there's a timeout of some sort), send the next one.
Have the user enter a message identifier in their message. You can then parse the identifier out and associate the reply. This is not very user friendly and they may forget or get the wrong identifier in the message
Use multiple numbers to send the messages. So, if you have an active message you are waiting for a reply to, use a different number to send out the next message. You can then associate the reply based on the number the user replies to.
The last option is my preference since it doesn't affect the messages you can send at any time and doesn't require extra work on behalf of the user. It does require extra work to build a number pool and do the work to associate messages with sending numbers.
I want to build an in-app chat application without any login.
So, the user communicates with the program (the backend), not with other user. So, it's a chatbot.
My question is: How to identify the user? Should I just log the IP address? Or, should I generate a random ID on server? Or, should I just generate it on the client?
As I understand, the purpose of identifying the user is for the server to keep track of who is sending the chat message and to send back the response to the appropriate client (user). IP address can't be reliably used as a way of uniquely identifying the user because of numerous reasons (it is a separate topic). One example of it would be this - A small company routes all the outgoing traffic from its office network via a single router that has a single IP address. In this case, the requests coming from different employees of that company would have same IP address as detected by the chat server. So it can't distinguish between these users.
The idea of generating unique identifier on the server for each user can work. A UUID or a JWT or something similar can be used to generate the id when the user initiates the chat for the very first time. This ID needs to be passed back to the client so that clients (users) can send the subsequent chat messages using the same ID. Thus, in this model, the client would need to have a place to store this ID so that it can keep passing it back to the server in its chat messages. Now the problem can happen when the client loses this ID. How can we recover from this situation? The answer would be similar to the approaches being used when someone loses their password. There are several recovery mechanisms such as sending the reset link on the trusted email address or sending it on user's phone as a code or generating a recovery key which is different from the ID and emailing it out to the user which can later be used to reset the ID. Basically, there should be an alternate and secure way (recovery flow) to identify the user if the ID is lost.
If the ID is generated on the client side, that can also work as long as all the clients are able to generate the ID that is guaranteed to be unique. Clients can pass in the generated ID to the server and server can check if it is already used and send a retry message to the client if it finds that it is already used. Or if the clients are using some hardware that has unique serial number and that serial number can be used to generate the ID.
In either cases, all the requests must pass in the ID to the server so that server can do the identification.
Hope this helps!
We have an application where in we need to notify a URL whenever a new user is created in the Google Apps Domain. The notifying url is https://projectId.appspot.com/userWatcher. Have verified the domain in the app engine console as https://projectId.appspot.com even then unuable to receive the push notification messages to the notifying URL. Kindly help me out
To use push notification make sure you do this things:
Register the domain of your receiving URL.
For example, if you plan to use https://example.com/notifications as your receiving URL, you need to register https://example.com.
Set up your receiving URL, or "Webhook" callback receiver.
This is an HTTPS server that handles the API notification messages that are triggered when a resource changes.
Set up a notification channel for each resource endpoint you want to watch.
A channel specifies routing information for notification messages. As part of the channel setup, you identify the specific URL where you want to receive notifications. Whenever a channel's resource changes, the Reports API sends a notification message as a POST request to that URL.
For more information check this page.
I've seen questions like Notify panel similar to stackoverflow's. It talks about the client side of the implementation.
I'm looking for the information about the server part and the networking part (how client get notified real time)
A user scenario might look like this:
something happens for user-a
server creates a message for user-a in DB (for persistance) : I'm using django-activity-stream for this
server sends (new or last 10) messages to user-a's browser (when user-a logs in or when event happens)
browser displays the message (Notify panel similar to stackoverflow's part)
if user acknowledges the message(clicking the inbox in SO), all the unseen messages are marked as read and recorded in server
I have questions on the following steps.
(3) Not sure but https://github.com/stephenmcd/django-socketio could be used.
(4) The answer to the question says client has the json data received from server.
Does server send messages to user for every request?
Does client check local storage(I'm new-to-web, what's a good local storage for this purpose?) and request the json data if he doesn't have them in the local storage?
(5) How should I implement this seen and unseen? django-activity-stream doesn't have notion of them.
This can easily be implemented by using django-channels.Because you need websockets to have a two way client server communication.
Showing notifications is a two way communication. Server notifies the client that a new notification available. The client shows this notification to the user, and then when a user interacts with the notification, the client notifies the server that notification was read, so the next time user loads a page, only unread notifications are shown.
There are some steps involved.
Your server needs to be able to support websocket communication. django-channel converts the application to ASGI.
Create a websocket consumer that can send and receive messages to a websocket.
When user opens the application, the client creates a websocket connection channel to the server.
Whenever a new notification needs to be sent, the server will send the message to the channel.
On receiving the message, the client renders the notification on the webpage using Javascript. Like showing the new message icon, appending the new message to the list of messages, etc.
Now, one part is done. Your user has been notified. Coming to the second part.
User sees the bell icon or whatever, and click on it, he sees the notification details (this was rendered by the js, when client received a message).
User clicks on the notification/bell icon. At this time, the client will send a notification back to the server, so that server can update what all notifications were read.
I created an app that updates the client when a new message is to be shown. Github link.
You can also refer to a similar question: https://stackoverflow.com/a/55656848/4186008
I would like to retrieve the cookies stored in the winhttp session cache based upon a specific host and path that I am about to send a request to. I want to retrieve those cookies before I send the request, so I don't have the request handle yet, all I have is the session and connection handles and of course the path and host I'm going to send the request to.
In other words I would like to retrieve the cookies that winhttp will send to the server before I actually send the request.
Reason I'm asking is because our server checks a specific header, which I have to set, to match an md5 check based upon, amongst other, the cookies. I don't have control over the server code or anything.
Cheers,
Use the WINHTTP_CALLBACK_STATUS_SENDING_REQUEST notification as a chance to inspect the cookie headers winhttp put by default on the request and then add the md5 header before returning from the callback.