Silktide can test websites protected by a username and password. The approach used depends on the nature of the password protection.
HTTP authentication
HTTP authentication is a common but basic form of user authentication. If a website is using HTTP authentication, loading it in Chrome will show a popup like this:
If your website uses HTTP authentication then Silktide will detect this automatically and ask you for the username and password automatically when you first add the website.
If you were not prompted, or if you need to update your HTTP authentication settings, go to Settings > Website settings > Authentication.
Other types of authentication
Because of the way Silktide sees webpages, it is able to support almost any other form of authentication, including web forms and even JavaScript / AJAX powered authentication.
Currently logging in to sites in this way requires a custom setup by one of our developers. The nature of this depends on the complexity of your login.
You’ll need to let us know 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.
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, and 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”, CAPTCHAs, 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 adds 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 sometime later when a user asks to re-test a page on your site.
What can cause problems?
Nearly all well-behaved websites that use web standards 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 that 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.