Is there a way to get the CA/Organisation name from a client that's initiating a session to a gin server through a custom client certificate?
As I see, both TLS.PeerCertificates and TLS.VerifiedChains are returning nothing useful.
Related
I have a http route /checkout which initiates a workflow process in Zeebe. The checkout route will return 200 response straight-away to calling client. Now, workflow will run for a while. So to push the response back to client after completion, I have a /sse separate route for server-sent events. Here, I will store all the client connection in a global map.
My doubt is how do I find the exact client to send the response back through sse once?
Example: Client A listening to /sse and calls /checkout endpoint which will return 200. The /sse has to return the response to client A after completion.
Currently, I thought of using cookie to identify the client. Is there a better way?
If you are already using cookies in your app than that's the way to go since the very purpose of cookies is identifying the client, so if you already have that, you should use it.
But if you rely on another authentication mechanism (like JWT), what you could do is using the url as a query.
So in the client instead of
let eventSource = new EventSource("/sse");
Do
let eventSource = new EventSource("/sse?authorization=jwt_token");
In the backend, you would validate that token, extract the Client ID and hit that global map with it to retrieve the corresponding connection.
(PS: instead of a global map, you should use a proper store, like redis, or an embedded key/value store like bbolt)
I am sending a websocket connection to the API server on a different host:
new WebSocket("ws://localhost:3000")
Whereas my front end is hosted on localhost:8080.
Inside my API's websocket connection handler I'm able to set a key on the session (with Sinatra's enable :sessions) but every time I refresh the html page, the data is lost.
Is there some requirement for sessions that the front end share the same host as the server? Or is there some way I can get around this? By the way, the front end is running on a Webpack server (Node).
I also tried adding a cross_origin allowance for the API's root route http://localhost:3000 and then doing this in the client (this example in coffeescript):
$.get "http://localhost:3000", ->
new Websocket("ws://localhost:3000")
My thinking was that maybe the session needed to be "initialized" over http:// instead of ws:// but it didn't work either. The session didn't work for the $.get "http://localhost:3000" request either. Refreshing the page shows that the session clears each time.
As we've discussed in comments, you probably have a problem with 3rd party session cookies in the browser.
Here's a scheme that you could use to work around it.
Client makes webSocket connection for the first time.
Server sends a webSocket message back with sessionID in it.
Client stores sessionID in a first party cookie (e.g. a cookie in the host web page).
User hits refresh.
Web page checks to see if it has a webSocket session cookie in the cookies for the host page. If so, it constructs a URL for the webSocket connection that includes that session ID `new Websocket("ws://localhost:3000?session=xyslkfas")
When server accepts webSocket connection, it checks the query parameters to see if there is already a session being specified. If so and that session is still valid, it hooks up that connection to that session. If not, it creates a new session and goes back to step 2.
I want to do place on server application which can be called by Go APP and Java app both.
for some reason ,there's a cookie authentication and oAuth mechanism ,so I want to set one Go app as Auth Micro-service for the authentication purpose.
As GRPC is built on the HTTP2 ,so The headers and cookies are on the protocol.but I did not find out how to carry on header and cookie when the rpc occurs,implemented by Go, on GitHub I only found the JAVA-Implementation for headers at :
https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/header
Can anybody give me some direction of Go implementation for this purpose?
Headers in gRPC are called "Metadata." Clients can only send "headers". Servers can send both "headers" and "trailers."
You want to:
Use the google.golang.org/grpc/metadata package and metadata.NewContext() to send metadata from the client-side.
Use grpc.SendHeader() and grpc.SetTrailer() to send metadata from the server-side.
Use the grpc.Header() and grpc.Trailer() CallOptions for receiving the Metadata on the client-side.
Use metadata.FromContext() for receiving metadata on the server-side.
Im learning Session Management and i have two questions for which i could not find answers on the web.
Once the user is authenticated, the Server creates the Session ID and sends it the client (user) in the form of a cookie. This cookie is then subsequently used in request the client sends to the server to identify himself among other users.
Now in HTTPS session, the requests sent between the client and server is secured, as requests from client are encrypted using the Public key and it can only be encrypted using the Private key which the server only has.
But initially when the server sends the cookie information to the client, it could be intercepted by anyone as even if this cookie which contais the session ID is encrypted using the Private key, it could be decrypted by anyone having the Public key. So, my question is :
1) how does the server make sure that the session ID created by the server is securely sent to the client.
2) I learnt the client sends the cookie for each request it makes to the server. In GET request, how does the client send the cookie information as GET does not include the body .
When HTTPS is used a secure connection is established before any HTTP requests are actually sent.
Transport Layer Security (TLS) and its predecessor SSL are not built on top of HTTP, but the other way around. They are one or two layers below HTTP in the OSI model. HTTP doesn't care whether the connection that it uses is encrypted or not. The browser just requests resources and sends header information such as cookies along with it.
You can check this yourself. Run a capture software like wireshark and look how the connection is established for a website using HTTP and HTTPS.
How can I make sure only a script hosted on a specific list of domains is allowed to connect to my WebSocket application?
Or to prevent opinion based closevotes, is there a state-of-the-art or native way?
I do not intend to implement user authentication.
The mechanism for this with WebSocket is the origin header.
This HTTP header is set by browsers to the domain of the host that served the HTML that contained the JavaScript which opened the WebSocket connection.
A WebSocket server can inspect the origin header during the initial opening handshake of the WebSocket protocol. The server can then only allow proceeding of the connection if the origin matches a known whitelist.
The header cannot be modified from JavaScript, and all browsers are required by the RFC6455 specification to include it.
Caution: a non-browser WebSocket client can of course fake the origin header to any value it likes.
#oberstet gave you the right answer.
If you are worried about bots or programmatic HTTP agents, then you are going to have a bad time. Everything in a HTTP request can be spoofed. Your only option is to use cookies to attach a token with limited time validity that certify the user went through an allowed website to get that script. Get that cookie in the WebSocket handshake and decide if you allow it or not.
E.g.: When a user visit your site, or one of your sites, return a cookie with a symmetrically encrypted token based on the user IP address, User-Agent header, and Origin header; when the user initiates a WebSocket connection, if it is in the same 2nd domain, it will send the cookie, then if the data adds up allow the connection, otherwise, reject it. If the WS is in another domain, then you will have to forget about cookies and rely on a web socket message once the connection is established to check the validity of the connection.