Dears,
Ocelot doesn't send my cookies for requests sent to downstream services
I have frontend, API Gateway and API Backend, each deployed on its own domain
But I can't configure ocelot to resend cookies obtained from frontend and send them to my downstream services
Related
I am trying to create a chat messaging application, which has text functionality. Right now, when a user sends an SMS message from their phone to a Twilio service number, there is a Twilio webhook which redirects to an endpoint in my backend server: sending HTTP POST request.
However, since it is a chat messaging application, I need the Twilio webhook to establish a Websocket connection (upgrading over HTTP) to my backend server, so that it can send websocket events back to my client.
Is there a way to establish a websocket connection using Twilio webhooks, or even Twilio functions? I can't find any resources online to solve this issue.
I tried Twilio Webhooks, and Twilio Functions, it hasn't worked so far.
WebSockets won't help you in this situation, as the webhook timeout limit is 15 seconds. This means you either need to return a TwiML response within 15 seconds or the request will fail.
It sounds like you want to build a stateful WebSocket connection instead of the stateless API callback. To achieve a stateful session, you either need to handle the state management over multiple incoming messages on your own, or you can use a Studio Flow which comes with state management baked in.
Here is the scenario that I have:
Client -> A SPA application -> a Proxy -> a Backend for SPA -> Service proxy -> Service Backend.
And I want to pass on the client IP all the way to the Service Backend.
I have tried using the X-Forwarded-For, but this only works with the first proxy hop. That is, Backend for SPA is able to get the original client IP.
It is the processes of forwarding this same client IP via Service Proxy to Service backend that I am not sure how to handle. Using the same X-Forwarded-For will pass on Backend for SPA IP address to Service Backend instead of the Clients IP
What is the recommended way of handling this situation?
The thought I have is to update the code in Backend for SPA to take the clients IP it gets via X-Forwarded-For, and put it in a custom HTTP header which Service Backend can then retrieve.
Is this the recommended way? or there is more idiomatic way to handle this?
I want to invoke HTTP endpoints at client-side using WebSockets. I am wrapping all required data like endpoint, payload, etc as a JSON and sending it to the client from server.
Now, the client which is running in the private network will make rest call to HTTP endpoint which is enclosed in the message and will return the data to the server.
I am not able to figure out the way to send the acknowledgment to the server for a message.
I am looking at developing a client - server application whereby the client will send a message to the server via our API performing an action. The web api (.NET) will hand off this message to a processing queue (Amazon queue at this stage) which will perform operations on it. I would then like to send a message back to the client to indicate that the message has been processed etc.
The only way I can think of to do this is to have the processing queue which is not part of the web api send a HttpPost or HttpPut to the same API my SignalR hub is defined which will send send the messages out to the various clients.
However performance is an issue of this application so I'm hesitant to do another Http call from the backend server to the API just to then get a message sent. Is there any other way I could look at getting these messages sent?
Pusher service works as illustrated here:
Does it make sense to use it in reverse direction (and switched data channels)? My use case is as follows:
end users (actually mobile, not browser) send messages to Pusher via HTTP-based REST API
my firewalled machine is connected to Pusher via WebSockets API, subscribes channel and receives messages in realtime
This way I can work with Sandbox plan (only 1 persistent connection is used) but mobile app must contain Puser app key.
From what I understand, anyone can use this key to register subscribe same message stream via websockets. Is there a reverse mode, where receiving messages requires knowing the secret? Maybe other service would suit better?
A more secure solution would be for the mobile clients to use client events. Client events can only be triggered on private channels where the subscription to the channel has to be authenticated.The authentication requests should got to an HTTP endpoint that you control so that you can validate the subscription request.
You firewalled machine can either then have a WebSocket connection and receive the client events over that connection. Or it could receive the client events via client event WebHooks if it exposes an HTTP endpoint.