I am using a jQuery plug-in to create a cookie (https://github.com/carhartl/jquery-cookie) and have been allowing the cookie to default to a "session cookie". Which is exactly the behavior I would like to have. My concern is that when I deploy my web site to Production, that it will be in a web farm on that environment. Can anyone help me understand what kind of issues, if any, that I will run into with session cookies on a web farm? The version of IIS on the web farm is IIS 7.5.
No issues at all. Cookies are stored on the client. They don't know or care about your server side infrastructure and how many nodes you have.
There are 2 types of cookies:
Session cookies - live only in the memory of the webbrowser and do not survive browser restart.
Persistent cookies - stored as files on the file system for a specified duration and survive browser restarts.
From the perspective of the server it makes strictly no difference. The cookie will be sent by the client on each request and the node that is serving the request will receive this cookie.
If on the other hand you are storing some information in the memory of the web server, such as for example using ASP.NET Session with the default InProc state then you will have problems. But this has nothing to do with client side cookies.
Related
So our team has created one dashboard using ruby, through that we are calling our APIs using NGINX proxy, so flow is like Dashboard will call NGINX Proxy which will call end system APIs.
Now the issue is we are authenticating requests coming from NGINX proxy by decoding the rack session cookie in the headers, which is working fine in our lower environments like dev/stage, but today when I moved our code to Production server, I saw that we are not sending cookies from Production servers, though it is recommended but we want that these cookies for our use case.
As I am new to this can, anyone help me how to enable sending cookies from production servers as well.
I was wondering that session management in cloud environments are available in many options for Microsoft azure/ Amazon Web Services / any private cloud. What I was looking that which is the best session management technique which will fit in all the cloud environments.
I have gone through many site but could not decide which is the most suitable in all cases. I read somewhere that Sticky sessions are also one of the option for session management. So looking for an answer which states that is Sticky sessions are different from cookie based session management?
If yes then how to use it?
Thanks
Ravi
Sticky session are likely to stay on same server when the first request comes and provided from same server for each request. Where as cookie based session are nothing but keeping the data on client machine in browser. can be served from any server which is available.
Yes Sticky Sessions are different than cookie based sessions.
As sticky sessions are nothing but handled by load balancers which handles to get sessions in request from client and passes it to the same server where the first request came to that server. E.g. While loading an website request goes to server A, then sessions get stored on server A, while next request comes from user the request sent to the same server i.e. Server A, irrespective of how many servers present in the farm.
Whereas cookie based sessions are stored on client machine, and it gets added with each new request. So it can be read and supported on any server in farm irrespective which server generated and stored session while first login.
I am running a Lab environment with Windows Server 2008 R2 and ADFS 2.0. I am also running Cisco Unified Communications Manager 10.5.1 (CUCM) and Jabber for Windows 10.5.2 which work with SAML 2.0.
When I go to the CUCM web page, I get redirected to the ADFS Forms Based Authentication page where I can authenticate with my AD credentials. I can then login to the web page fine. When I close the web page and re-open it, I am re-directed to the ADFS FBA page once more.
From my understanding, there are two types of cookies in SAML; Session and Persistent. I am also of the understanding that Session cookies are limited to a single browser instance and do not survive exiting the browser while Persistent cookies are available to all browser instances and expire after a set time.
My questions are:
Is my above understanding correct WRT Session v. Persistent cookies?
Are Persistent cookies enabled by default in ADFS 2.0 or do they have to be enabled?
If already enabled, why does the above scenario happen? (looks like to me that only Session cookies are being used)
Thanks,
Daniel
WebForm :
In webform (with session) state application in web farm environment the session is stored in SQL Server storage which can be accessed by all the servers in a webfarm. This means the logged in user's request can get the same session regardless of which server in the farm it hits.
WebAPI :
I understand that webapi by design is stateless so for true webapi application I dont need to worry about how the state is maintained etc. Usually the authentication token is passed between requests and as far as its valid a login gets access to the whatever resource it needs on the server. This is fine with one Webserver hosting webapi. But what about web farm. How does the "Session" (Or the equivalent term in Webapi) is managed in WebApi farm?
I know azure gives following options to name the few..
Azure SQL Server
Azure Table storage /Queue
Cache Service
They seems to add extra complexity to the architecture (which is much easier in WebForm using SQL Server Session).
One other slightly different question (and might a bit basic) is how does the request/response is traced in webapi farm? i.e. When a client make request to webapi and webapi sends a async response how does server make sure its traced back to the client?
Edit:
I am not looking to implement Session is Webapi but rather how the same thing can be achieved in webapi without session state.
Thanks
Yes. Using session in REST is a really bad thing.
But you can simulate the session in Web API as well. In web form, the server added the generated session id in HTML from so when user submit that session id will be included in their request. You can simulate the same thing with Web API as well. You can check this Accessing Session Using ASP.NET Web API
The best that you can store the information in memcached or redis with expiration. It will work in web farm as well.
Anyways, I don't recommend using the "session" in Web API.
For a web application I could figure no session cookies stored . There was a string as
SSLJSESSION=0000SESSIONMANAGEMENTAFFINI:-1
From my understanding , this cannot be used to handle sessions , Still the application is handling the sessions properly .
Can anyone please tell me how session handling is done with the above technique ?
After a bit of browsing through WebSphere’s documentation, I found out that WebSphere (actually IBM HTTP Server as well as SUN One Web Server) support a feature called SSL ID Session Tracking. Basically, what this does is bind web application sessions to SSL sessions. This further does not require the web application to do almost any session handling since the server performs this on behalf of the application.