Silktide can test websites protected by a username and password. The approach used depends on the nature of the password protection. A website that uses HTTP authentication can be created and managed by the admins in your Silktide account. We can also give our crawler instructions for completing a login form.

HTTP authentication is a common but basic form of user authentication. If a website is using HTTP authentication, loading it in your browser will show a pop-up like this:

If your website uses HTTP authentication, Silktide will detect this automatically and ask you for the username and password 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.

For sites that don't use HTTP authentication, we can still configure our crawler to navigate a login form. These custom authentications may incur additional costs, so this will generally need to be discussed with your Customer Success Manager.

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.

Beyond that, there are a few things to know about our custom authentications:

While both are similar, Authentications are really only meant to log in to a given system. The steps of an Authentication should contain little more than what is needed to log us in to a website. If we need to complete one or more forms or processes inside that website, those would be covered by a User Flow.

This actually works in your favor to speed up tests. An Authentication is set up to run anytime we detect that we are logged out. If the Authentication process also includes a 30 step online form, then we would be completing that again every time we think we've logged out. Pulling that out of the Authentication means we can quickly log back into the website and continue testing as we were.

All of your details are encrypted via SSL and stored behind multiple levels of security. To test your pages, we need to store the login details (for example, username and password) that you give us – we can’t store this as a non-reversible hash. In addition, we also store the contents of the pages behind the login so that they can be tested and viewed within the platform. Some links on your site could cause changes, such as logging the user out or changing the user's data. With that in mind, we should not test an environment where we can change someone's real data.

Putting those items together, you may need to create a dummy account that we use for testing. This account should not be able to access sensitive data that you wouldn't want us to store and test. That also ensures we aren't changing real data related to a real user.

As mentioned above, we aren't able to complete a CAPTCHA or retrieve a code from a multi-factor authentication (MFA) step. If you need additional security for our scanning, you can adjust the user agent or IP addresses used by our crawler during the scan. This can make our traffic identifiable on your side, which you could use to get us through any systems that would keep us out. For an additional cost, we could even investigate setting up a VPN to VPN connection to scan the site.

If your site uses HTTP Authentications, you can set that up right when you add the site to your account. If you need a custom authentication, reach out to your Customer Success Manager to see if you have any available in your account's contract.