There is a site which accepts logins from the same user until browser is restarted. I try to simulate this in JMeter with HTTP Cookie Manager. I defined cookies, use those in all the logins, but seemly it doesn't use those. After successful login site enables only the same user to login until browser is closed, but I can login with other users too in same JMeter test execution. I use standard Cookie Policy.
You don't need to define cookies manually, JMeter's cookie manager manages cookies automatically
As per the documentation:
The Cookie Manager element has two functions:
First, it stores and sends cookies just like a web browser. If you have an HTTP Request and the response contains a cookie, the Cookie Manager automatically stores that cookie and will use it for all future requests to that particular web site. Each JMeter thread has its own "cookie storage area". So, if you are testing a web site that uses a cookie for storing session information, each JMeter thread will have its own session. Note that such cookies do not appear on the Cookie Manager display, but they can be seen using the View Results Tree Listener.
If you need to mimic "Logout" you can tick Clear Cookies each Iteration box and each Thread Group loop (iteration) will simulate "clean" login.
See HTTP Cookie Manager Advanced Usage - A Guide for more information on HTTP Cookie Manager use and troubleshooting.
It is possible that the web site is not using cookies at all for the purpose of tracking logins, and instead uses "browser session storage". (See https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) And it is possible that the cookies that you see are added by other parties / sources, for example google analytics etc.
Related
I have an ASP.NET Core web app with an API that requires users to be authenticated. About a month ago, I realized I could no longer use Postman API tool because even though I'm authenticated, my API calls would get a response as if I'm not authenticated.
When I look at available cookies under cookies tab, I see four of them. I recognize one of them but not the other 3.
The cookies I'm seeing in the "Cookies" tab in Postman while making API calls are:
ARRAffinity
.AspNetCore.my_cookie
_ga
_gid
All four cookies are showing my domain. The only difference I've noticed is that the second cookie show mydomain.com while others show .mydomain.com. I recognize the second one because I name my cookie i.e. my_cookie. That one is also the largest one which also makes sense because I store some information in the cookie. I assume, .AspNetCore prefix is added by my app because it's an ASP.NET Core web app with API.
What are the other three cookies? Do I need them?
The other important thing I've noticed is that when I use Fiddler to inspect my API call, under "Cookies" tab in Fiddler, I only see the tree cookies that I couldn't identify being sent with the API call. I do NOT see the one that I recognize which is issued by my site.
Looks like my issues with Postman have something to do with these three unidentified cookies being sent with the API call but not the one that I issue i.e. .AspNetCore.my_cookie is NOT being sent with my API call.
_ga and _gid are used to collect Google Analytics data.
Name - Expiration Time - Description
_gid - 24 hours - Used to distinguish users.
_gat - 1 minute - Used to throttle request rate.
if you want to know more about Google Analytics cookies, please read this
In the other hand, for ARRAffinity. Windows Azure Web Sites, by default, use an ARRAffinity cookie to insure subsequent requests from a user are routed back to the web site instance that the user initially connected to. In other words, Windows Azure Web Sites assumes your web site is not stateless. If you were to scale your web site deployment to multiple instances, the ARR Server processes this ARR Affinity cookie and sends you back to the instance that processed your initial request (the request that originated the cookie).
If you’re not already familiar with this, check out this blog for an in-depth discussion on ARR Affinity for Web Sites and how to disable ARR Affinity if your web site is stateless.
If the session is stored in proc
The user logs in, closes the browser directly and reopens it after an hour. Would he need to log in again?
If the web application uses cookies and cookies are enabled on the users browser...
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the web application uses cookies and cookies are disabled on the users browser...
If the web application uses persistent cookies and cookies are disabled on the users browser...
If session is stored in state server and situations are the same, then what would happen?
When a session is created (assuming it is a normal session), a cookie is sent to the browser that looks something like this:
SESSION_ID=437b930db84b8079c2dd804a71936b5f
Sessions can be used without cookies if the session identifier (in the example above, 437b930db84b8079c2dd804a71936b5f) is passed around as request parameter instead of a cookie; however, this is rather uncommon and it is generally considered bad practice.
All session information is stored server-side, and the session identifier is used behind-the-scenes to decide which set of information should be recalled (if any) for each request. Thus we get to your questions.
If the web application uses cookies and cookies are enabled on the users browser...
If the web app uses cookies and cookies are enabled on the browser, then there should not be a problem. With a standard session implementation, the cookies will be non-persistent, though, so the user will need to login again if he/she completely closes all instances of the browser.
If the web application uses persistent cookies and cookies are enabled on the users browser...
If the session-id is stored in a persistent cookie and user's browser respects that by persisting the session identifier cookie to the disk, then the session identifier will be sent even if the browser is fully closed and restarted. However, please be aware that most web frameworks have a garbage-collector-like system that deletes data for sessions that have showed any activity over a certain amount of time. So, for example, let's say my website requires activity at least once every 4 hours to keep a session active. If I login, receive a persistent cookie with my session ID, close my browser, and come back 5 hours later, then I will need to login again because my session information would have been cleared from the server even though my session ID cookie was persistent.
If the web application uses cookies and cookies are disabled on the users browser...
Bad news bears. You will either need to find a way to use a cookieless session (passing an identifier as a parameter for each request), or you will need to ask the user to enable cookies. There is no way around this.
If the web application uses persistent cookies and cookies are disabled on the users browser...
Same situation as #3. If the user has cookies disabled, you are out of luck. Either they need to enable cookies (at least for your site), or you need to find another way to pass around information between requests.
Session is stored in server memory (unless a state server or persistant store is used) but relies on a cookie to identify the session. If cookies aren't available then session won't work since there is no way to identify the user. Cookieless sessions can be used to get around this. Cookieless sessions aren't recommended as they can be hijacked with the session identifier in the url.
If an expiration isn't set on the cookie then it will be lost once the user closes all browser instances (they share memory) and not just the one visited through the website.
If the user has cookies disabled, then cookies aren't available for use by the application. People aren't as worried about cookies now as they were in the late 90's (lots of "security" people raised warnings that cookies could be used to store all sorts of things on your computer, even viruses).
What is the common(best practice) way of allowing a user to sign in from a Windows desktop application. Some examples of what I mean are Dropbox or Google Picasa. You sign in with your credentials and then the software is permanently signed in.
I assume the communication takes place over HTTPS. Does the client store the credentials to be sent with requests or is there some sort of token generated? Can anyone point me to some resources on how this should be handled?
Logging into a website normally creates a session at the server. The server then has to identify subsequent requests by the session. Typically, there is one of the following two solutions applied:
Session cookie, storing a session identifier
URL rewriting, where the session identifier is appended to every link in the html source
Which approach is taken is site dependent, so if you are writing a general 'for all sites' client, you might have to implement both.
In the former case, your application will have to handle the session cookies, in the second case, your application has either nothing to do - if it caches the html response - or will have to emulate the url rewriting itself.
In both cases be aware that the session will expire at server side after a certain period without any activity, so you might be required to generate such.
Seeing as using session and cookies are so unsafe, is it possible to securely use just servlet context variables and hiddenform fields, url rewriting to implement same things that session does?
But will it be equally secure and convenient? Why is this method not used?
I am just trying to avoid cookies! Plus, if I save user details in servlet context variables , will it not work same as cookies, but just in server side?
Is that the reason that cookies are ultimately used,That they are client side?
No, Cookies are different from Servlet Context. ServletContext is singleton per application. Not per user.You should avoid using ServletContext for user specific information because you also need to take care of User Lifecycle such as deleting the User info when he is idle.
If you do not want to use Cookie, the alternatives for session tracking are:
URL Rewirting
Hidden Form Fields
But you can make Cookies Secured with the help of following properties:
httponly: On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript).
secured: A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server.
Domain : They tell the browser that cookies should only be sent back to the server for the given domain.
Path: They tell the browser that cookies should only be sent back to the server for the given path.
Suppose I have logged into an application which is running from IIS. Now I haven't logged out, but closed the browser. And when I'm accessing the application again, it defaults to the login page. How does IIS recognize that it is a new request and redirects the user to the login page?
I have another question. Suppose if I'm not closing the browser, which I used when I logged in. I'm opening the new browser to request a page from same application. IIS recognizes that it's a new request to the application and redirects the user to login page. Why does it not use the existing session or cookies which the first browser uses?
Please don't get irritated of my continuous questions... I am having huge confusion.
We say HTTP is a stateless protocol. Once the page is requested I have logged in. And the HTTP protocol connection will be terminated between IIS and browser, right? Then I am navigating to other pages in that logged in application. Now IIS recognises the user has logged in on this browser. But when I open a new browser and request that application, how does IIS recognises it is a new request? Since the HTTP protocol is disconnected, how does it work in the first case?
As you've correctly said, HTTP itself is stateless, and each request is technically separate from every other. Sessions, as used by web sites, are a workaround for that. What happens, normally, is that the server stores whatever info it cares to maintain between requests (like the logged-in user's username and/or ID, for example), and assigns that information an ID (called a "session ID"). It then tells the browser that session ID, in such a way that the browser can hand the ID back when it's time to make another request. If the browser plays its part and provides the session ID, then the stored information can be retrieved, updated, etc with each request, providing some degree of state even over a stateless protocol.
Sessions are usually implemented using cookies. That is, the server hands the browser a cookie with the session ID, and the browser hands back that same cookie with each request until the cookie expires or is otherwise forgotten. Some cookies (so-called "session cookies") aren't saved, and are forgotten when the browser is closed. A freshly opened browser doesn't have any session cookies to pass, so if the server uses session cookies to do sessions (which it should), it will consider the user not yet logged in and bounce them to the login page if they need to be logged in.
Session cookies will usually be shared between tabs in the same browser, and will sometimes even be shared by windows opened by "File > New Window" from an already running browser, because both of those cases will typically just be a part of that browser. But if you start the browser from the Start menu, or however your OS lets you start a program, it's a whole other process -- and session cookies are rarely shared between processes.
The server typically also only remembers sessions on its end for a limited time (anywhere from seconds to years, depending on the server and/or site settings) after each request that uses the session. If the browser passes a cookie that corresponds to a session the server no longer remembers, it'll act as if there's no session at all. Which, in cases where you have to log in, will again bounce to the login page.
There are cookies that are passed always no matter are you logged or not. They are mapped to session in IIS.
Check out the following articles. They might be helpful.
IIS Dropping Sessions
Session Management in ASP.NET