I would like to have a simple performance test which logs in multiple users, the sessions are created and do not expire until n minutes (where n is a parameter).
Is it possible to do this with JMeter? Do JMeter invalidate sessions at the end of the test?
In general, the expiration times of your cookies have to be set on the server side. The actual implementation will vary depending on your server side technology stack (see e.g. here for PHP's session docs), but it should be feasible, for example, to make a simple page that recognizes an "incoming" GET parameter value (from jMeter) for setting the cookie's expiration time when issuing the cookie.
On the client side (jMeter) the straight forward way for managing sessions is by using the CookieManager component. Each thread will have its own session cookie until the end of the test (or until the end of the iteration, if you configure the CookieManager accordingly).
If your test targets a typical web application that uses login forms for user logins, you could login each user (i.e. thread) e.g. by reading credentials from a username/password list in the form of a csv file (see CSV Data Set Config) and posting these credentials to the login form's action URL.
see httpd.conf (in Apache) for information on setting the duration of the session before timeout. This timeout is offset from the last request from a given session.
Related
I'm struggling to understand how flask_login or django knows when a user logs in that they retain access?
If I were to use ReactJs or Angular with flask-restful or django/tastypie, what is being added to the header/body of future json requests to ensure that my user stays logged in?
This is done via sessions, which is based on cookies. From the Flask documentation:
In addition to the request object there is also a second object called session which allows you to store information specific to a user from one request to the next. This is implemented on top of cookies for you and signs the cookies cryptographically.
and the Django docs:
Django provides full support for anonymous sessions. The session framework lets you store and retrieve arbitrary data on a per-site-visitor basis. It stores data on the server side and abstracts the sending and receiving of cookies. Cookies contain a session ID – not the data itself (unless you’re using the cookie based backend).
So, the requests to the server automatically include a cookie that indicates some ID that the server then uses to figure out what the session data should be for the given user. In general, when Ajax requests are made from client-side applications to the server, this cookie is included and so ensures that the user is considered to be logged in for those requests.
In some cases, you can also (optionally) manually add a special header to HTTP requests to indicate which user is logged in.
See also Securing RESTapi in flask for some more information.
If you use REST service then you should take a look at oAuth. In other words it uses token which you attach to every request from client to server and the last can determine which user sent this request by this token.
On the other hand, you can use cookie or session to determine a user status. And in this case you don't need to add any headers to your request.
Also I recommend you this package for Django - Django Rest Framework (there you can read more about token and auth via REST) and this extension for Flask.
I am testing an application that requires a user to authenticate, and then uses a cookie to track the user session. If authentication fails, a cookie is set that identifies the session as belonging to an unidentified user.
Unfortunately, authentication is via Kerberos or NTLM, which cannot be done in JMeter 2.8. My plan is therefore as follows:
Log into website with Internet Explorer.
Copy cookie that identifies session out of IE and into JMeter cookie manager as a user-defined cookie.
Use JMeter to test application
Essentially, this is session hijacking.
What I am observing is that (1) the JMeter cookie manager does not seem to be supplying the cookie to the application in the first request, (2) after the first request the application sends a different cookie back to JMeter, and (3) subsequent requests use the application-defined cookie, not the one I supplied.
So my questions are:
Is the approach described plausible, in theory at least?
Do application-defined cookies always override user-defined cookies?
Why might the cookie manager be not sending my user-defined cookie?
Thanks in advance.
Try using JMeter nightly build, it has been reported recently that it worked with NTLM after upgrade of httpclient libraries.
http://jmeter.apache.org/nightly.html
You approach seems really weird to me and I don't think it will work or even if it does be realistic.
I don't really understand when session is created and per what entity it is created (per ip, per browser, per logged in user). I see in documentation that sessions by default is created per visitor - but what is visitor (browser or ip)?
What are HTTP sessions?
To display a webpage your browser sends an HTTP request to the server, the server sends back an HTTP response. Each time you click a link on website a new HTTP transacation takes place, i.e. it is not a connection that is persistant over time (like a phone call). Your communication with a website consists of many monolitic HTTP transactions (tens or hundres of phonecalls, each phonecall being a few words).
So how can the server remember information about a user, for instance that a user is logged in (ip addresses are not reliable)? The first time you visit a website, the server creates a random string, and in the HTTP response it asks the browser to create a so called HTTP cookie with that value. A cookie is really just a name (of the cookie) and a value. If you go to a simple session-enabled Django site, the server will ask your browser to set a cookie named 'sessionid' with such a random generated value.
The subsequent times your browser will make HTTP requests to that domain, it will include the cookie in the HTTP request.
The server saves these session ids (for django the default is to save in the database) and it saves them together with so called session variables. So based on the session id sent along with an HTTP request it can dig out previously set session variables as well as modify or add session variables. If you delete your cookies (ctrl+shift+delete in Firefox), you will realize that no website remembers you anymore (Gmail, Facebook, Django sites, etc.) and you have to log in again. Most browsers will allow you to disable cookies in general or for specific sites (for privacy reasons) but this means that you can not log into those websites.
Per browser, per window, per tab, per ip?
It is not possible to log into different GMail accounts within the same browser, not even from different windows. But it is possible to log in to one account with Firefox and another with Chrome. So the answer is: per browser. However, it is not always that simple. You can use different profiles in Firefox, and each can keep different cookies and thus you can log into different accounts simultaneously. There are also Firefox plugins for keeping multiple sessions, e.g. MultiFox.
The session all depends on which session cookie your browser sends in it's HTTP request.
Play around
To get the full understanding of what is going on, I recommend installing the FireBug and FireCookie plugins for Firefox. The above screenshots are taken from FireBug's net panel. FireCookie will give you an overview of when and which cookies are set when you visit a site, and will let you regulate which cookies are allowed.
If there is a server side error, and you have DEBUG=True, then the Django error message will show you information about the HTTP request, including the cookies sent
It's browser (not IP). A session is basically data stored on your server that is identified by a session id sent as a cookie to the browser. The browser will send the cookie back containing the session id on all subsequent requests either until the browser is closed or the cookie expires (depending on the expires value that is sent with the cookie header, which you can control from Django with set_expiry).
The server can also expire sessions by basically ignoring the (unexpired) cookie that the browser sends and requiring a new session to be started.
There is a great description on how sessions work here.
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.
I want to understand the logic of authorization,cookies,users logins,sessions..Do you know any source that explain and teach me about it. If it could give any examples it would be great. I mostly use php,jsp but it would be no problem if you give answer related other languages.
The cookie is primarily used to maintain some state on the client side between the requests on a specific domain and/or path. The session is primarily used to maintain some state on the server side between the requests on a specific domain and/or path.
The session is usually backed by a cookie. In PHP it's the cookie with the name PHPSESSID and in JSP it's the cookie with the name JSESSIONID. Both contains a long, unique autogenrated value.
The server side has a mapping between the cookie value and all attached session objects in the memory. On every request, it checks the cookie value in the request header and reveals the attached session objects from the mapping using the cookie value as key. On every response it writes the cookie value to the response header. The client in turn returns it back in the header of the subsequent requests until the cookie is expired.
With regard to authorization/logins, you can put the logged-in User object in the server side session and check on every request if it is there and handle accordingly. On logout you just remove the User object from the session or invalidate the session. In PHP you can access the session by $_SESSION and in Java/JSP by HttpServletRequest#getSession().
The principle is the same in all other web programming languages.