Web URL Patterns

The Web URL Patterns window is used to configure domains or regular expressions that you wish to track with KeyServer. After specifying patterns in this window, “usage” (i.e. access) of those URLs will be tracked by clients in supported browsers Supported Browsers
Windows: Firefox, Chrome, Edge, Opera
Mac: Firefox, Chrome, Safari, Edge, Opera
Linux: Firefox
and reported to KeyServer. Note that MacOS has special considerations. The URLs will appear as entries in the Programs window - which can then be added to products and policies much like traditional executable based programs. Once a policy has been made, KeyServer will record usage, which can then be reported in the same way as traditional program usage - looking at where URLs are accessed, how often, and for how long. As it becomes more common for software to have purely web-based components, this unified view of usage is important.

Adding Entries

You can create these patterns either in the dedicated window, or by way of making a new web-based product. For the latter, see New Product Wizard. It is generally considered easier to create the Pattern in the process of making the Web Product, which makes the Program entry in the background.

Config Window

Open this from KeyConfigure - Config - Web URL Patterns. You will see this same interface when stepping through the new Product wizard. First you will need to click the + button at the bottom left to add a new pattern. You will be prompted to choose between a domain or a pattern. If you want to track a single domain all as a single object, use the Domain choice and enter something like example.net. Then any URLs within example.net will all be reported as the same entry in the programs window. Note that when using this option, matching URLs (i.e. "hits" by the client) must start with http:// or https:// - “ftp://ftp.example.net/” will not match and won't be recorded. You can also enter the exact Identifier you would like to use for this domain - or if you leave it blank an Identifier will be generated for you, e.g. “@example.net”.

     URL Patterns Window

If you need more flexibility than this, you should use a Pattern instead. Using a pattern allows you to target a specific URL or set of URLs within a single domain, e.g. “mysite.org/private/”. You can also use a regexp pattern, e.g. “^https?://[-a-zA-Z0-9_.]+\.ly/”. When specifying a pattern, you must explicitly choose an Identifier, you can not click Add with the field blank. For consistency and simplicity we recommend Identifiers start with the @ symbol and contain no spaces or special characters other than dash.

     Edit URL Pattern

After you have added new Domains or Patterns, clients will learn about it, but a client computer reboot may be needed. Additionally, any running browser when a pattern is created or changed will absolutely need to be quit and relaunched for the new pattern to be recognized. Once a client learns a new pattern, it will notice when that pattern is accessed in any major browser, and report this to KeyServer. The first time KeyServer learns of a new Identifier an entry will appear in the Programs window and it can then be used in a product. It is important, whether you add a Domain or a Pattern of your own, that you test to see that it is working as expected - identifying the expected URLs and not identifying additional URLs. To do so you will first need a Product and Policy to begin gather usage (access to) the URLs.

You can also add new Domains or Patterns within the Product Wizard. When added via the Product Wizard, a program entry will be created with the identifier, which is added to the new Product.

Additional Details

Creating a Pattern requires knowledge of regular expressions. While there are plenty of resources for these, frequent confusion has indicated some common use cases and examples are prudent.

Putting all these items together you may have a pattern like ^https?://([-a-zA-Z0-9_]+\.)?somedomain\.com/account. This indicates (as we read through it) the pattern starts with http and might include an s but does not have to, with normal :// url syntax. Then we allow for the possible presense of any alphanumeric characters in any order or quantity possibly existing as a sub domain. This means anything.somedomain.com will trigger the pattern, but more generally www.somedomain.com or just somedomain.com will both trigger it as well. We then escape the . in .com and end the pattern with /account. This means the base url of somedomain.com will not actually trigger the pattern as it does not end with /account, but /login would not trigger the pattern. If we removed the ()? grouping then sub domains would not trigger the pattern. It is advised you make a paterns as specific and simple as possible to avoid possible unexpected results in matching.

Note that you can Edit an existing pattern, but if you change the Identifier you will need to allow a new Program to be created on first access which can then be updated in the Product. In other words, it's often easier to delete a pattern and related Product and make a new Web Product instead.

Note the blue bars on the left of the pattern list. This indicates the order the patterns were added to the server, as well as the order they will be processed in. These can not be altered, so the priority is set by order of creation. This means if you need to target a more specific pattern before a more general one (or domain), you must create them in the order of most specific to most general. If they are in the reverse order, the general pattern will catch the specific URL, and your specific pattern will never be triggered.


Note that KeyAccess 7.5 or higher is required to be able to track URLs. Also, while URLs can be tracked (as well as do things like display grant messages), KeyAccess cannot prevent any pages from loading. A supported browser Supported Browsers
Windows: Firefox, Chrome, Edge, Opera
Mac: Firefox, Chrome, Safari, Edge, Opera
Linux: Firefox
must also be used, the agent will not see use by other browsers. Due to technical limitations, in some browsers despite the site being accessed it may not be seen as in use if the tab in question is not the active tab. This does mean that usage data will be somewhat incongruous with the actual authenticated use of a SaaS site for example.

Since URL access cannot be blocked, we recommend policies for products that contain URLs be configured in such a way that they will not try to prevent usage. Specifically, they should be Observe policies, Manage policies with the Site metric, or Manage policies with other metrics but with an Enforcement option of “None”. Finally, any options such as Background Warning, Queue & Notify, etc should be avoided as they could result in KeyAccess presenting confusing messages to the end user.