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 your browser will show a popup like this:
If your website uses HTTP authentication, Silktide will detect this automatically and ask you for the username and password automatically when you first add the website.
If you ever need to update your HTTP authentication settings, select the Settings button in the top-right corner of your website report to load the website settings screen. Select the Go button beside your website homepage URL to open the login details fields.
Don’t forget to Save once the changes have been made.
User journeys
Silktide can support nearly any form of authentication, including web forms behind VPN network protections. The nature of the approach taken depends on the specific configuration and complexity of your authentication method(s).
User journeys can be configured in Silktide to automatically fill out user web forms, including login forms. These are programmed as a series of manual steps, similar to Selenium. For example: click a field, enter a value, and submit a form.
Some technical considerations about authenticating with a user journey:
Silktide tests web pages using a headless Chrome browser. This means we run the web page JavaScript, AJAX and so on as a user would.
Parts of your page are referenced via selector (for example
input[name=login]), so a predictable selector must exist for your user journey to work.Although we support some conditional logic, non-linear authentication forms are generally not feasible, for example "enter the nth digit of your password", CAPTCHAs and so on.
The authentication state (browser cookies and local storage) is gathered immediately after logging in, then stored and shared between all of our workers as they download your site.
We can customize the number of simultaneous workers if needed. By default, there are 6 workers and they alternate between desktop and mobile viewports.
Silktide adds a conditional check to ensure that we have been authenticated or otherwise logged in successfully, for example confirming the name of our test account appears in the corner of the screen. This is usually done using a simple text or CSS selector match.
We use this check to detect when we need to re-authenticate, potentially during a re-crawl or later when a user asks to retest a page on your site.
Common issues
Nearly all well-behaved websites that use web standards correctly will work easily with our user journey technology. Unfortunately, some older and proprietary systems do not always behave this way.
If some links are not idempotent – that is to say, visiting a page has side effects – we may need to exclude them. The most common example would be when a link logs the user out. 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 temporary URLs that exist only for the moment they are first requested, for example 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.
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 the login details (for example username and password) that you give us – we can’t 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, as well as the pages that this authentication information provides access to, are not sensitive in nature. We strongly recommend the use of a dummy account for this purpose.
Contact support
To get started, you’ll need to let us know the web address of your login page and ideally supply authentication details to a test account. We use these to confirm our technology can log in and test any pages behind the authentication.
Websites with authentication methods that require us to access over a VPN or requiring a user journey to fill out custom web forms will incur additional costs if they are not already included as a part of your contract.