I have some access to socks5 server (host, port, username and password). I need to be authorized and then make several requests to different servers by TCP via this socks5 proxy. How I can make it with node.js?
I found library socks-client and it is ok, but I have to be authorized for each request to remote server (by using method 'connect'). How can I solve my problem?
That's the nature of the SOCKS protocol. You connect, authenticate, and then if successful normal data is transferred back and forth on the same connection. There is no way to re-use a connection, so you have to repeat the process for every new connection you want to make.
Related
Let's say I want to build dynamic chat app.
I want to update users activity status. I can do this with backend requests every x seconds.
But for example Discord can do this without any requests (nothing in network tab in Chrome).
How can I do this? Thanks!
For this type of requests it's the server who sends the response to the client without requesting in a stream
not the usual HTTP requests where the client request something and the server sends the response so it's either you use SSE (server-sent-event) unidirectional tunnel or you use a socket which is bidirectional tunnel (socket.io for example) but for this need sse are better so you don't need to check every x seconds the server notifies the clients subscribed to this tunnel it's like a notification
check these links:
server-sent-event-1
server-sent-event-2
We have a Google http(S) LB in front of a Google Compute VM, and we are routing a subdomain to the backend which exposes only a wss endpoint. I couldn't find any example for javascript code how to use Authentication with Google IAP and OIDC Tokens.
Does Google IAP support query parameters for the authentication ?
I found this entry:
Bearer authentication for websocket
Thanks for any advice
There is no method in the JavaScript WebSockets API to customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that are sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible. One way to attain this is using a “ticket”-based authentication system.
When the client-side code decides to open a WebSocket, it contacts
the HTTP server to obtain an authorization “ticket”.
The server generates the ticket. It typically contains some sort of
user/account ID, the IP of the client requesting the ticket, a
timestamp, and any other sort of internal record keeping you might
need.
The server stores this ticket (i.e. in a database or cache), and
returns it to the client.
The client opens the WebSocket connection, and sends along this
“ticket” as part of an initial handshake.
The server can then compare this ticket, check source IPs, verify
that the ticket hasn’t been re-used and hasn’t expired, and do any
other sort of permission checking. If all goes well, the WebSocket
connection is now verified.
Refer to the link for websocket security and related stack posts HTTP headers in websockets client API and Websocket authentication.
I would like to show a list of connected users without using Websockets.
I thought to use http header Connection:keep-alive
to get persistent connections.
Then, when clients leave the website, they would run a listener handler on beforeunload event in order to notice server that a client is going to leave the list.
But, how is server able to notify the rest of connected clients to update their lists? (remember, without using websockets, and if possible, without making clients asking any interval to server)
So using the Connection: keep-alive header means that the browser and server will carry out multiple http requests/responses over one tcp connection vs opening and closing a tcp connection for each http request. But this still doesn't allow the server to just push data whenever. For the server to respond with anything, the client still would need to make requests. So it isn't really related to real time push events.
and if possible, without making clients asking any interval to server
This isn't really possible. Like I said, a server cannot send data to a client over http unless the client first requested it.
So you either have to make interval requests for the user list
or
you can make it "simulate" pushing from the server with http long-polling.
The basic idea is that the server never "finishes" its response to a client request, but sends its response in chunks, when really those chunks would be treated on the client side as separate pieces of data. But this solution is hacky and has a lot of cons. Either way, http long-polling would more or less simulate pushing data real time.
I know there are no standard JS WebSocket APIs for the same. My main aim is to send the info like resourceId, routingInfo, auth-token, protocol etc. from JS web-socketclient to the server.
I could think of below few approaches. Kindly share the thoughts if my approach is fine or is there any other better approach:
Can we use cookies for sending the custom headers from client and retrieve them in server side?
Can we use web-storage API for storing them in the browser and retrieve them on server side?
PS: I am using a Java based server
Assuming you're talking about a webSocket connection from a browser, here are your traditional choices for sending additional "header-like" information.
You can encode them as a query parameters on the initial URL which might be fine for everything except auth-token.
If the origin you are connecting the webSocket connection is the same as the origin of your web page, then you can put the parameters into cookies and those cookies will be sent with the original webSocket connection request where the server can retrieve them upon the connection request.
You can make a "conditional" webSocket connection to the server and then send credentials in subsequent webSocket messages. You'd have to implement safety for that on your server so that the "conditionally" connected webSocket was not allowed to do anything else except authenticate itself and probably timeout the connection if appropriate credentials do not arrive shortly.
As it sounds like you may already know, the browser interface to webSockets does not allow custom headers on the initial HTTP request that starts the webSocket connection. Those custom headers are possible from some other kind of client - it's just that the browser interface to a webSocket connection does not have that feature.
Can we use web-storage API for storing them in the browser and retrieve them?
The Javascript in your web page can use the web-storage API to store data in the browser and that data can be retrieved later from another script in a page from the same origin. That data is not available to the server, it is only available within the client.
I have two web-servers responding on two different ports. I have the main web server that serves a website with a lot of javascript behind HTTP digest authentication, the secondary webserver only executes CGIs that can be directly accessed, always by using HTTP digest, or that can accessed with CORS by the ajax requests related to the main webserver. Both servers share the same users credentials.
My problem is that I don't want the browser to prompt for credentials when the javascript is making requests to the secondary webserver.
I came out with the idea that I could add some special header in the ajax request to the secondary web-server, and if this header is present I can ignore the HTTP authentication. Since the servers share the users credentials, if the user is able to log in into the main web-server, he'll be able to login into the second one as well.
Using a fixed header is of course useless. So the question is: is there a mechanism in CORS to tell the secondary webserver that the user is already authenticated in the first one? Something like a safe way to exchange tokens in cookies?
If it is only the ports that are different cookies will be shared across these origins. So if you know for sure that a cookie is set once the user accesses origin 1, they will be included in requests to origin 2, as long as (assuming you're using XMLHttpRequest) withCredentials is set to true.
Now of course those cookies should contain some authentication data that you verify before you let them bypass HTTP authentication.
And hopefully you're using HTTPS so that the credentials are safe from network attackers.
I'm not sure this has anything to do with CORS. What you need is a single-sign-on solution for the two different servers. You could implement a full-blown OAuth solution, or write a simple one yourself.
For a simple token-based authentication, you'd do the following:
When the user logs into your website, send down a expiring token (over SSL) that grants the user access to the web service.
Take the token and do a GET request to a non-authenticated endpoint in the web service. If the token is valid and non-expired, send an authentication token back to the browser.
As long as your web service implements HTTP authentication properly, the cookie will be set and the service calls won't prompt for credentials.