I have a perl web application (CGI::Application with ModPerl::Registry) which connects to a authenticated custom server over a socket and exchanges data (command/response) with it. Currently the web application connects to the server, authenticates and disconnects on every page request - even for the same user.
Is there some way I can use the same socket over multiple page requests which share a common session id? Creating a separate daemon that proxies connections and makes them persistent is an option I am exploring, but would like to know if there are any simpler solutions.
I have no control over the design of the custom server unfortunately.
Looks like the same question was asked on PerlMonks. The responses there point in the right direction, but the issue seems to be that you want one cached connection per session, not one cached connection per session per httpd thread/process. You might have to resort to a separate proxy process to get the behaviour you want.
Related
I am developing a chat back-end application on aws cloud. In order to make a scalable architecture for the chat back-end I must ensure that the one who is opening a connection is the real one.
To be more accurate that chat ofcourse must keep a tcp connection open with the server all the time and I have the following problems:
1 - the back-end has a load balancer elastic load balancer.
2 - the tcp connection between the client app and the back-end server must stay open and alive. which mean the app must keep the connection alive with the server not the elb load balancer.
3 - the elb load balancer must send the connection and load through a session table sticky session to the same server the app connected to before.
unfortunately, the load balancer only support l4 and l7 layers and I think I need to use the l3 layer.
the main problem here is most people operate behind proxy server so I can't maintain a connection with them because the tcp connection will be made with the proxy and not their app.
I don't know how to solve this but the only solution that I know now is:
I must prevent the users from operating behind any proxy servers to make sure the tcp connection is direct with them not the proxy, how do I do that?
If there is a way to let them operate behind a proxy and a solution can be made on the back-end tell me.
I'm not sure I understand your concern. If you are using web sockets, most proxies would allow this type of communication but they can cause you troubles as well if they have timeouts and such.
You cannot control whether someone is behind a proxy. In many cases the proxy will be completely transparent so you'd have no way to know it is there without inspecting all of the network hops. You may want to read up further on this. A good start is this article -
https://www.infoq.com/articles/Web-Sockets-Proxy-Servers
If you are attempting to use the IP address as an authentication mechanism, I suggest instead using a standard authentication mechanism. Once authenticated, you should manage the session using either session cookies, JWT, or another standard session management solution. Note that JWT is typically stateless (doesn't use a session) but can be used to authorize a user to session type data.
I have a question about the reason the web applications continues setting cookies, because the persistent HTTP conections use sockets, i.e.: websocket.
HTTP 1.1 and 2 uses persistent http conections, with sockets in the client and server. These sockets are active a necessary time for loading a complete web page (HTML, CSS, images, etc), then the sockets are killed by the server. It is logic due to the server does not know what is doing the client. So, in this scenario, the use of the cookies is justified.
But, with websocket i think the scenary is different, because it uses only one socket, so it means that after the conection is done, the server and the client uses the sockets for sending data.
So, the question is... why are the cookies necessary if the server know who is the client?
This question is impossibly broad, since many different web applications work in many different ways.
In general, cookies are used to store data that needs to persist beyond the momentary connection between the client and the server.
More specifically, the connection between the client and the server can be very transient. The server receives a request, sends a page, and moves on to the next request. It doesn't maintain a constant connection to every browser that contacts it.
I am thinking of adopting Loopback.io to create a REST API. I may need the following approach: an inTERnet server (run by me) to which clients connect, plus a fallback inTRAnet server to which clients connect only in case the internet connection is down. This secondary fallback server should then replicate data on the main server when the internet connection is up and running again. As clients are on the same inTRAnet they should be able to switch automatically to the fallback server. Is this possible as an idea and if so, what do you recommend i start digging into?
Thank you all!
Matteo
Simon from my other account. I believe what you want is possible as you can use whatever client side technology you want with LoopBack. As for easy solutions, I'm not familiar enough with Cordova to give any insight there.
It is definitely possible, but I suggest going through the getting started tutorial first. You'd probably create two application servers and have another proxy in front to route the requests to server a or b based a heartbeat from the main server. You would have to code all the logic and set up the infrastructure yourself though.
I have a RESTful web-service application that I developed using the Netbeans IDE. The application uses MySQL server as its back end server. What I am wondering now is how often a client application that uses my RESTful application would refresh to reflect the data change in the server.
Are there any default pull intervals that clients get from the RESTful application? Does the framework(JAX-RS) do something about it Or is that my business to take care of.
Thanks in advance
#Abraham
There are no such rules. Only thing you can use for properly implementing this is HTTP's caching capabilities. Service must include control information how long representation of a particular resource can be cached, revalidated, never cached etc...
On client application side of things each client may decide it's own path how it will keep itself in sync with a service. It can be done by locally storing data and serve end user from local cache etc... Service can not(and shouldn't know) how clients are implemented, only thing service can do is to include caching information in response messages as i already mentioned above.
It is your responsibility to schedule the service to execute again and again. We can set time out interval but there is no pull interval.
I want to notify the browser side via javascript about an approaching session timeout.
My current implementation polls a URL every so often to find out if X seconds remain until session timeout.
For purely academic scaling reasons, what is an alternative to polling for session timeout on a Torquebox2 environment?
For example if I use a websocket server, how do I add session timeout information for the user and is it possible to have the client side trigger immediately after the information is pushed?
Is there a simple gem or alternative that does the bulk of work for me?
Web sockets would surely be better than polling.
There is a good example of web socket usage in torquebox here https://github.com/torquebox/stomp-chat-demo
In this example, session information is set and read both in the Sinatra application and in the stomplets (analogous to an http controller but for web sockets). The documentation for web sockets in TorqueBox shows how to use the session both in your application controller and your stomplet here http://torquebox.org/documentation/current/stomp.html#d0e3602