Understanding Dependencies and Wildcards in Securly Classroom's Allow-Only Blocking Plans

When using allow-only blocking plans in Securly Classroom, it’s important to understand how URL dependencies work and how to manage these dependencies effectively. This article will guide you through the rules and nuances of adding URLs and dependencies for blocking plans.

1. Complete URLs for Web Links

When you create a new web link (or update an existing one), the URL must be complete. This means it should include:

• The protocol (either http:// or https://).
• The domain name.
• Optional: The www. prefix (though this is not mandatory).

For example:

• Correct: https://example.com
• Correct: http://www.example.com
• Incorrect: example.com

If a user forgets to add the protocol, Securly automatically defaults to http://.

2. Understanding Dependencies

Dependencies are URLs that are necessary for the proper functioning of certain websites. For example, websites often require access to external resources like fonts or APIs. When adding dependencies:

• The protocol (http:// or https://) is not required.
• The www. prefix is optional.
• Wildcards are allowed at the beginning of a dependency and are very helpful for allowing multiple subdomains.

Wildcard Rules:

• A wildcard can only be used at the start of the URL.
  • *apis.com will allow requests to googleapis.com and fonts.googleapis.com.
  • *.googleapis.com will allow fonts.googleapis.com, but not fontsgoogleapis.com.
• Wildcards in the middle of a URL (e.g., clients*.google.com) are not allowed.

Examples:

• *apis.com (Allows any domain ending with apis.com)
• *.google.com (Allows any subdomain of google.com)

3. Blocking URLs

URLs that you want to block (either at the organizational or personal level) follow specific rules:

• They may or may not have the protocol or www. prefix.
• Paths after the domain name are ignored. If there is a path (e.g., example.com/path), it will be automatically stripped when sent to the device.

Example:

• https://example.com/path will be treated as https://example.com.

4. Allowed URLs (Org-Level)

Allowed URLs at the organizational level act similarly to dependencies:

• They can start with *. or * for wildcard usage, allowing all subdomains of a given domain.

For example, adding *.google.com will ensure that all subdomains of Google are allowed.

5. Common Pitfalls to Avoid

• Incomplete URLs: Ensure that URLs include at least a domain and a top-level domain. A valid URL must contain at least two parts (e.g., google.com).
• Wildcard Misuse: Remember, wildcards can only be used at the beginning of a URL. URLs like clients*.google.com will not work.
• Adding a Path to Blocked URLs: Paths in blocked URLs will be ignored, so there’s no need to add them.

If you encounter any issues or have further questions about configuring URLs and dependencies for allow-only blocking plans, please reach out to Securly Support for assistance.