I have a setup with two applications running on cloud foundry. Application G works as reverse proxy with public route. Application A with internal route runs behind G. Container to Container Networking has been set between G and A. Now due to scaling, A has multiple instances. I need sticky session for A. But the problem is C2C networking does not go through Go Router so let A set JSessionID cookie does not work here. How to make sticky session happens?
Traffic to your application will look like this:
Browser -> load balancer -> Gorouter -> App G (reverse proxy) -> App A
If App A is setting the cookie JSESSIONID as its session cookie, that will still trigger Gorouter's sticky session support, however, it will only apply to App G, which doesn't really help in this case.
This is also something you need to consider if you scale out App G in the future because you probably don't want or need that since your reverse proxy won't be storing state in the session. You could change this behavior by using something other than JSESSIONID as your session cookie or having your reverse proxy rewrite the session cookie name.
In terms of having sticky session support for App A, you need to configure your reverse proxy i.e. App G to do this. How you do that depends on your reverse proxy, which you didn't specify in your original post. Check the docs for your reverse proxy for instructions on enabling "session persistence" or "sticky session" support.
Related
With a hardware LoadBalancer, you can configure sticky sessions which will make sure the same session will always go to the same server.
But will this work with webservices also (rather than webservers)?
i.e. I have WebServices hosted behind a Load Balancer.
Will Webservice calls coming from different native clients (not browser clients) always go to the same webservice server?
These are very old style Webservices - uses RPC/Encoding - the native client program uses Axis 1.4 for the client stubs.
Webservice calls coming from different native clients (not browser clients) always go to the same webservice server should be possible.
To maintain the session stickiness, mostly load balance inject the server identifier in cookie while responding back to the client(kindly note cookie is not a browser feature it is HTTP feature defined by this specification) and should be supported by the HTTP client which is used by Axis 1.4 underneath).
I suggest you to to analyze how your load balance works and based on that you may have to change your needs to change your clients. If your load-balance uses the cookie based approach, this answer you may found useful.
Hope this helps.
If you can keep your application stateless,make it it's good in both performance and scalability.
Benefits of stateless :
Scalability. You can have as many servers as we want without having to share a user session. Each of them can process request (e.g. load balancing via round robin).
Saves server resources. We do not need to allocate memory on the server side (again - scalability).
No need to recover after a server restart.
Session stickiness can be tricky to get right. For example, if your web servers are running on multi-core machines, and you have several processes handling web traffic, you'll need a way to be sticky to both a specific machine and a single process on that machine. So make sure your system degrades well in cases where stickiness doesn't work correctly.
Good discussion you can find here : Sticky and NON-Sticky sessions
Sticky session pro and cons :
Pros and Cons of Sticky Session / Session Affinity load blancing strategy?
Now come to your question :
Will Webservice calls coming from different native clients (not
browser clients) always go to the same webservice server?
Yes in sticky session .
These are very old style Webservices - uses RPC/Encoding - the native
client program uses Axis 1.4 for the client stubs.
Session configuration you need load balancer/server and it can handle any old or new type of applications
this work with webservices also (rather than webservers)?
No its configuration you need to make on server level.
It will work as long as your native client correctly manage the session, ie. set the correct http header for each request.
Generally sticky session is managed by the load balancer by modifying the session cookie to add the server identity.
HA-proxy example
There must be a dedicated documentation for your load balancer.
I am looking at two WSO2 client samples that call the user management web service. The first is a simple client, the second is a web app.
The first client sets the system SSL properties and then instantiates a WSUserStoreManager object.
The second one, the web app, does not set SSL properties at all, and instead instantiates a RemoteUserStoreManagerServiceStub.
Could someone please explain why these differences? What service to call when two similar are available (a regular and a 'remote' one)? Isn't it always necessary to set up the SSL properties when calling a https endpoint? Thanks.
if you are calling to HTTPS end point, you need to set the SSL trust store properties to trust the server. But it is under control of the client, If client wants, it can trust it, if not it can ignore. If you want to ignore, you want to override default TrustManager of java.
However, normally java has a trust store file called "cacerts" where it contains all trusted CA certificate. But WSO2IS server's certificate is a self signed one and java can not trust it. Therefore, if you want, you can import certificate in to the "cacerts file. I am not sure about why there are two different in client and web app. However, if you are calling HTTPS, trust must be created. Please check web app source more. Some time, it may have ignore the trust. As web app is run in a app server, sometime java SSL trust properties may have been set to correct file.
I had a problem that Fiddler wasn't showing my web service calls made from my application (running locally). I found and solved my problem.
So my question is not how, but why does Fiddler not show web service traffic? I have a very limited understanding of how network traffic works so this might be quite simple/obvious. All I'm able to decipher is:
I don't think it has anything to do with HTTPS, as I can see HTTPS requests in Fiddler (decoded if I want through Fiddler's settings).
I copied a piece of code new WebProxy("127.0.0.1", 8888); in order to get it to work so it must have something to do with proxies?
This is an ASP.NET application in case that makes a difference.
Really old question but:
While the answer and comments hint towards the right solution, they are far from answering the question.
Fiddler sees traffic by your user account. Since web services run by the application pool identity, fiddler cannot see their traffic.
The easiest solution (and the only one that worked for me) is to change the website application pool user to run under your account
Simply:
Open IIS
Find your website application pool name (right click website -> Manage Website -> Advanced Settings -> Listed under Application Pool)
Go to application pool advanced settings (Application Pools -> Right click your desired application pool -> Advanced Settings)
Change User Account to your account (Identity -> ... -> Custom Account -> Set)
As noted above:
That first paragraph was just the explanation I needed: When Fiddler launches and attaches, it adjusts the current user’s proxy settings to point at Fiddler, running on 127.0.0.1:8888 by default. That means that traffic from most applications automatically flows through Fiddler without any additional configuration steps. Although I guess I should also thank Eric as he appears to be the one who wrote it!
References
Capturing Traffic for .Net Services with Fiddler
adding the following content inside the config is also a solution.
<system.net>
<defaultProxy enabled = "true">
<proxy bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
Also, if the traffic from the web service is pointing to another application in same localhost, try using the machine name instead of localhost in the request url.
I have a small Linux server acting as a reverse proxy running Nginx. The main server behind Nginx is running a website in asp.net with a forms authentication login and an instance of ArcServer, running some REST services on port 6080.
Is it possible to only allow traffic to port 6080 on Nginx to people that have a session cookie from the asp.net login? Basically I only want logged in users to be able to access those REST services and not the whole wide web.
If someone could point me in the right direction, I am running short on ideas.
Thanks.
The following works quite well. But naturally is only a bit of obfuscation and doesn't replace any security checking deeper in the app
location /url/to/secret/ {
if ($cookie_secretCookieName) {
proxy_pass http://serverhere;
}
}
This wouldn't prevent anyone that knows the cookie name from getting access e.g. someone who was a user and isn't anymore; but it could be a nice extra step to reduce a bit of load on your servers
We are working on an HTTP webservice load-balanced using haproxy. The webservice is accessed via SSL. It is a RESTful HTTP service and simply accepts JSON, does some work, and returns JSON. There is no notion of a session.
We have redundant load-balancers set up in front of a pair of redundant webservice servers. Each server sits behind Apache, where Apache is used as a proxy in order to handle SSL and logging. If it matters, our webservice is a Clojure (java) application using compojure (jetty) to handle HTTP.
This is a brief diagram showing the path of a client request through our existing system.
client request -> haproxy (load balancing) -> apache (ssl, logging) -> webservice
We would like any connection to the load-balancer to establish a persistent connection and then be served by the same server for all subsequent requests sent through that persistent connection. In other words, we don't want a persistent connection to haproxy making requests to more than one webservice server.
How would you recommend that we get this working? How can we "pin" a given connection to the load-balancer to a specific webservice server? How could we prevent accidentally loading down a specific webservice server with multiple intensive requests?
Using balance source in the defaults block, along with removing option httpclose entries did the trick.
In our HAProxy configuration we do this at the backend level, using the cookie option. This is because he have a number of sites, some of which we do want persistance for - others we do not.
In those that we do the backend looks like this in haproxy.cfg:
backend examplesite
cookie STK insert indirect nocache maxidle 30m maxlife 8h
server server1 192.168.0.1:80 cookie n1
server server2 192.168.0.2:80 cookie n2
This will set a cookie with the name STK on the first request. Haproxy will automatically assign a value to this cookie that it will then use to send subsequent requests to the same node.
We decided to also add the n1 and n2 cookie prefixes... this means that the cookie value will be prefixed with either n1 if the requests are going to node 1 or n2 if they are going to node 2. This is very helpful when debugging.
Either way I'd suggest taking a look at the configuration documentation around cookie options.
You might also want to look at the appsession option. This allows HAProxy to use an existing cookie (such as ASPNetSessionId or PHPSESSIONID) for the same purpose.
I had problems with it before, but recently had an answer to a question of Server Fault which should resolve this. You could give it a go as it saves using an extra cookie in your requests. Can't get appsession setting in HAProxy to work.