Cookie isolation for testing - http

I would like several instances of a web-page at once for testing.
Each time with a different user, and hence a different cookie.
To save time, I would like to run these tests in parallel.
The problem is that browser instances share cookies. Hence two users cannot be logged in on the same computer on the same browser in different windows at the same time.
I am looking for a way to run several pages with different cookies at the same time.
I am open to any solution: PhantomJS, Selenium, etc...

I am sure that the selenium instances of firefox dont share cookies. You can go with selenium. What happens is, when a selenium session is invoked, it creates a temporary profile of the browser in the TEMP directory(for Windows) and performs all the operations on it. You can do yours as follows Create a firefox profile, and configure it such that it never remembers the history and use that profile to invoke browser . For other browsers, keep the default settings as that they never remember the History

After login you can try deleting cookies for the current session by using selenium.deleteAllVisibleCookies() method of selenium RC.

As you may be aware, cookies are bound to domains.
If you could get each page or tab to use a slightly different domain (like an alias), then these cookies could coexist.
This domain aliasing could be accomplished using proxy server.
I've gotten results in the past using Privoxy.
Recently, I've tried using mitmproxy which I've written about here.
https://gist.github.com/sharedvices/6098357

Related

How to close ASPSessionId in a Visual Studio Web/Performance Test

I have finally given up on this and I'm looking for some help on this. Here is what I have found so far.
First of all, web performance tests and/or load tests in visual studio do NOT use the browser (during playback it's not used, but it is used during the recording of the test) which is when/where the ASPSessionId is stored in a cookie or form post parameter.
I have web performance tests that have extraction rules to get the ASPSessionID from the server which I try to set in a later request as header/form post parameter, however this doesn't seem to help and it appears that I am just using the same one over and over causing the server to respond differently (presents different pages)
On the system I am testing a user will go to the site and fill out an application. If the user is in the same session the user can fill out multiple subsequent applications and have the ability to re-use some data. If that is true, the user is presented a page to select the re-usable data. If the session is new the user does not get to do this.
If I play the web test over and over manually, it works as expected (new session ID, no re-use data page presented). However, if I play that same test over and over in a load test, the first time it will pass and each time after it fails, because the session is kept open and then the server provides different pages than the ones that exist in my web performance test. The failures on the subsequent applications includes fails like (expected response URL, extraction rules...etc)
So I was using an extraction rule to get the ASPSessionID from the server and store it in a cookie and/or web form post parameters and then set it, but it is not working.
What can I do in the web performance test to successfully close the ASPSessionID so that the test runs like it is running for the first time in the load test?
In the LoadTest Test Mix, set the "Percentage of New Users" to 100. That completely solved it for me.

IE8 Session sharing problem in ASP .Net Application

I am having ASP .Net application which is running perfectly in IE 7.0 but as due to session sharing in IE 8.0 (also in case of new window), application is giving unexpected behavior as session can be modified by other window.
Some quick facts
I know the -NoCache option and open New Session file menu item of IE 8
I just wanted to know that is there any option to disable this session sharing behavior in new window through ASP .Net code (by getting the browser) or any other solution
I also wanted to have your suggestions for future web application development, what we need to take care to avoid session sharing issue
Session sharing has always been there is not unique to Internet Explorer 8. New tabs, Ctrl-N in any browser (IE5,6,7 FF1,2,3 OP6,7,8,9,10 etc) shares the session data of the global process. It just received a fancy name because now tabs can have multiple processes on the computer (not new either), but will still "share" the sessions. And thats' kinda "new".
It is good that you're aware of this, but it's not so good if you're trying to take this "experience" or "feature" away from the user. If you want that, I'd check into JScript/JavaScript solutions instead and issue a warning when a user tries to open several sessions, but I doubt you'd get a good "prohibit sharing sessions across windows" solution. Even notable banks have already given up on this (they never liked this session sharing thing)
From a design perspective: on the server side, it is rather simple. Just always assume that the session is changed. This can, for instance, mean that on one screen, the user is not logged in, on another he is. That's ok. If he refreshes or goes to another page, you'll show him the correct view: logged in user for the same page.
Just make sure that you check for invalidated data as the result of a changed session in another window (i.e., request). But that's a general advice: be liberal in what you accept, but make sure you validate any input.
EDIT: On extra sessions: just treat them like that. It has always been possible that users open up more then one session for the same user (two different browsers). Just as it has always been possible to change a session through another tab, window etc of the same browser.
On the "solving" side: Configure the session as cookieless. This places the session in the URL query params. Any old window not having the SESSIONID in the URL will not be considered part of the session. However, a warning is in place: this approach eventually causes more trouble then it solves (i.e., now you have to worry about with and without session requests from same user, same browser, same ip and it's still possible to "copy" a session by copying the URL or tab).
Moving some of your information from Session to ViewState may help you solve the issues you are having.

How should I create cookie through flex/coldfusion that is readable by another template?

Inside a flex app, I have a user login. The login calls a ColdFusion function as a remote object which authenticates the user and, if applicable, returns their id and access level.
This works fine, but now I'm at the point where I want to also create a cookie for another ColdFusion template (called from fileReference.upload()) to be able to access later.
I have tried several different methods for creating the cookie -- cfcookie, creating a cookie with JavaScript inside the ColdFusion function, and creating the cookie with JavaScript with an external interface once the coldfusion function returns to the flex result handler. All of these have been tried with a plethora of options regarding expiration, path, and domain tags.
Any of these seems to work for cookie creation. Cookies show up in listings for my domain in Chrome as well as in a Firefox add-on 'View Cookies 1.9.2' that I've installed just for this purpose. Yet, still, none of these cookies seem to be readable by my upload.cfm when it is called later.
The upload.cfm, once called by a file upload request, sends the user id along with the file. From here, it should be a simple comparison between the id sent with the file and the id from the cookie. So far, the upload.cfm template has been unable to find the cookie (with any of the creation methods) looking at the obvious #cookie.name# or even #name#.
I'd appreciate any insight into why this is occurring, or perhaps an alternative method to the security I'm attempting to implement.
Thanks for reading,
-cs
Have you done most/all of your testing in a browser other than Internet Explorer?
Unfortunately, there is a bug in the Flash player [login required], which can be summarized as:
(In browsers other than Internet Explorer) The flash player uses a different network stack than the browser, and therefore...
Requests made by the flash player have a different server-side session than, for example, the request for the page that embeds the flash player.
This causes a situation whereby session variables set by the page are not (easily, by default) available to remote requests made by the flash player on the page.
CFID and CFTOKEN are set as cookies as well as stored in the session.urlToken variable. (JSessionId is included as well, if you're using Java session management).
I'm not positive, but I think this may be the root of your problem.
I believe that if you pass the CFID and CFTOKEN (and JSessionId) values to your Flex application as FlashVars, and then include them in the remote requests to the server, that the cookies you're setting will be available to later remote requests by flash (i.e. your upload).

Loadrunner asp.net application

We have an asp.net 3.5 web app that we must start load testing with LoadRunner
What we have found is that if you open several browsers (ie8) they share the same session id, so making a change in one window impacts the other windows (not just our app, others app also).
Now, LoadRunner can simulate a number of users per pc, and so we are finding its getting messed up since its all sharing the same session.
Any ideas on what is the best method to prevent this (we don't want to go with cookieless sessions).
How would you ensure each browser window is treated as a unique session?
This is a 'Feature' of IE8 :-S.
You can however start IE in a "start with new session" mode though. use:
iexplore.exe -nomerge
Not to sure how this would be applied to LoadRuner though (Never worked with it)
session/state is unique to a single user, but not across users. You will need to correlate both session and state data across your scripts and then you should be able to execute mutiple users on a single load generator without issue
Whether a new browser session is opened is purely a client side issue. The server does not know or care that a different browser session has been instantiated and is only responding to a valid request as indicated by session token, security token, state token, etc...
While replaying scripts in loadrunner, it doesnt invoke the IE and it wont have impact of the tabs.
Use the setting Check for newer versions of the stored pages every visit will help on this issue.
Also you can put clear cache and cookies before each iteration.so that each time new sessions will be created.

How can I share a session across multiple subdomains in ASP.NET?

I have an application where, in the course of using the application, a user might click from
virginia.usa.com
to
newyork.usa.com
Since I'd rather not create a new session each time a user crosses from one subdomain to another, what's a good way to share session info across multiple subdomains?
You tagged this with ASP.NET and IIS, so I will assume that is your environment. Make sure you have this in your web.config:
<httpCookies domain=".usa.com"/>
If your 2 subdomains map to the same application, then you are done. However, if they are different applications you will need to do some additional work, like using a SQL Server based Session storage (and hacking the stored procedures to make sure all applications share the same session data) or with an HttpModule to intercept the application name, since even with shared cookies and the same machine key, 2 applications will still use 2 different stores for their session data.
Track your own sessions and use a cookie with an appropriate domain setting, ie. .usa.com.
Alternatively, if you're using PHP, I believe there's a setting to change the default domain setting of the session cookie it uses, that may be useful too.
The settings you're looking for are:
session.use_cookies = 1
session.use_only_cookies = 1
session.cookie_domain = .usa.com
I recently went thru this and learned the hard way. Localhost is actually considered a TLD. Cookie domains require at least a second level domain - test.com. If you want cookies to work for a domain and all it's sub-domains, prefix with a '.' - .test.com.
When running/debugging locally, setting a domain of localhost will fail, and it will fail even if the domain is set properly because visual studio uses localhost by default.
This default localhost can be changed in the project properties so that the project will actually run at cookie domain test.com. Essentially, if the address in the browser matches , you can get it to work.
My issue is documented here: Setting ServiceStack Cookie Domain in Web.Config Causes Session Id to Change on Every Request
Hope this helps.
If you're using PHP, one hack would be to make a little include script (or two) to do the following:
1 Serialize your $_SESSION array
2 Pass that string as a hidden input, making all your links to those buttons in separate forms using POST.
3 Also include a boolean hidden input to let your script know whether it needs to use the current session or unserialize $_POST['session']
4 Deploy this across your site, calling things where appropriate
I wouldn't do this if there's actually a sanctioned way to transfer a session. I hope you've at least considered using cookies.
Matt's answer is definitely the way to go if you have multiple subdomains pointing at the same IIS app (which is exactly the situation I have right now, using wildcard DNS and then doing subdomain 'sniffing' on the receiving end).
However, I wanted to add something that I experienced in case anyone is finding that this is not working for them. Setting the httpCookies line alone didn't do it for me, I had to add a machineKey entry into my web.config file:
machineKey decryptionKey="12...D1" validationKey="D7..8B"
Particularly odd since I am not in a web farm setup (unless AWS/EC2 is effectively acting as such).. As soon as I did this, it worked like a champ.

Resources