Testing logged in areas of your website

Silktide Monitor can be used to test private logged-in areas of your website. This requires some manual work from Silktide, the nature of which depends on the complexity of your login.

Testing feasibility

Firstly check if the website is using HTTP authentication, which in Chrome appears as a popup like this:

This is the most basic type of login, and Silktide can handle this automatically with no manual work.

If this is not the case, some development is required.

The fastest way to confirm your login is testable is to tell Silktide the web address of your login page, and login details for a test account. We use these to confirm our technology can log in and see pages behind that login.

Alternatively we can give you some technical details on how our process works (below), which you can run by your developers. This may not be enough be able to confirm feasibility, but in some cases it may rule it out.

How we test logged in areas

This section is technical and is designed for people who work on the website you are looking to test.

• Silktide test using a headless Chrome browser. This means we run all your page’s JavaScript, AJAX etc as a user would.
• Login is programmed as a series of manual steps, similar to Selenium. For example: click a field, enter a value, submit a form.
• Parts of your page are referenced via CSS selector (e.g. input[name=login]), so a predictable CSS selector must exist for your login to work.
• Although we support some conditional logic, non-linear logins are generally not feasible, e.g. “enter the nth digit of your password”, CAPCHAs, etc.
• Your authentication state (the browser’s cookies and local storage) is gathered immediately after logging in, stored, and shared between all of our workers as they download your site.
• We can customize the number of workers, there are 6 by default, and they alternate between desktop and mobile devices.
• Silktide add a conditional check that a user is logged in (e.g. confirming their name appears in the corner of the screen), this is usually a text match or a CSS selector.
• We use this check to detect when we need to re-authenticate, potentially during a crawl, or some time later when a user asks to re-test a page in your site.

What can cause problems?

Nearly all well-behaved websites that use web standard correctly will just work. Unfortunately, older and proprietary login systems do not always behave this way.

• If some links are not idempotent – i.e. visiting a page has side effects – we may need to exclude them. The most common example is if a link logs out the user; more serious examples would include links which create or delete data. For this reason you should only ever test with a dummy login account.
• Some logged-in pages use entirely temporary URLs, which exist only for the moment they are first requested (e.g. they contain a unique session ID and/or encrypted application state). Although we can sometimes still test these, they are much more difficult to set up and some parts of Silktide are incompatible with them (e.g. you can’t view the history for a page, as no page exists more than once).

Security implications

All of your details are encrypted via SSL and stored behind multiple levels of security. However, you should be aware of the following:

• To test your pages we need to store your login details (e.g. username and password) that you gave us – i.e. we can’t just store a non-reversible hash.
• We store the contents of the pages that we download so they can be tested, and viewed within our platform.

Therefore you should ensure that the login details you give us, and the pages that this login provides access to, are not sensitive in nature. We strongly recommend the use of a dummy account for this purpose.