WebSurge can optionally track cookie data for all requests, but in a multi-session environment cookie tracking can be tricky. By default cookie tracking in WebSurge is off.
To enable cookie handling the following approaches are possible:
- Manual - each request explicitly provides the correct cookies
ReplaceCookieValues- allows assigning a single shared cookies to all sessions
TrackPerSessionCookies- Tracks shared cookies for all sessions
Manually handling cookies means you use valid cookies in each of the actual request headers of each request. This requires that cookies have not expired and likely means that you either capture requests right before running them or you explicitly capture and update cookies for requests.
This is not optimal of course as cookies do expire and need to be changed.
This option allows you to set a single cookie in the configuration value, that is then applied to every request that is run by a session or individual request.
This allows login cookies to be set once, and then automatically share that cookie with every running session. This works as long as it's realistic to use a single cookie/session with all request clients and is an easy way to get all requests running with cookies.
This setting captures cookies in a global cookie container and makes cookies available to subsequent requests. Like the ReplaceCookieValues option, this works fine if you can use a single cookie for all sessions as the cookie values are shared across all sessions.
which means that cookies have to be manually provided per request. This means requests need to include cookie information or use the
ReplaceCookie configuration setting that can automatically replace
In order to run Web requests on a typical Web site you probably will need to be able to track cookies on the site. HTTP requests natively are stateless and so cookie data is not automatically captured and passed forward.
WebSurge provides a couple of ways to seed Cookie Data:
Cookieheader in your HTTP request
ReplaceCookieValuefor a global replacement value
The explicit way to set Cookies is by capturing requests that include a given Cookie header. When you capture requests you the Cookie is part of the captured data.
This works but has a major disadvantages:
Cookies typically have a timeout associated with them and when the original cookie expires your Cookie header is no longer valid. You either have to update the cookie with a valid cookie, or your can use the
As an alternative you can capture a single valid Cookie value via a tool like Fiddler or via browser Dev tools. The following captures a Cookie via the Chrome Dev Tools (F12 in browser):
You can capture the cookie value and assign it to the Session Options -> ReplaceCookieValue setting.
When you set this value it will override the Cookie value for every request that is sent to the server. This may or may not be what you want, but in most cases this is a quick and easy way to add Cookie values that are valid for your test session.
TrackPerSessionCookies as the name suggests works on a single session and essentially captures cookies created by requests and then passes those cookies through the rest of the session. Using this approach you can set up a session that starts with a login request sets a cookie and then access authenticated requests that require that same cookie - the cookie is automatically captured and sent with subsequent requests in that session.
For this to work it's important that you use sessions that include login links that create the Cookie before you access any authenticated links that require Cookie to be present. Order matters in this scenario.
TrackPerSessionCookies can also be useful for individual URL tests. The IDE essentially executes individual requests as a single session. So you can run a Login link with a fixed username and password to create an auth cookie, and then hit other requests that expect that cookie and it will be set.
To clear cookies for a project, switch the
TrackPerSessionCookies flag to
False and then back to
Comment or report problem with topic