Tag: host-resolver-rules

The Power of Multiple Incognito Windows

Posted on by Leave a comment

Custom User Data Directories and Advanced DNS/TLS Management

In the world of web development, testing, or any activity requiring precise browser session handling, juggling multiple configurations can quickly become overwhelming. Fortunately, modern browsers like Google Chrome offer powerful features that, when combined with a bit of command-line magic, can make your life significantly easier. Let’s dive into the usefulness of having multiple incognito windows using different user-data-dirs and managing TLS certificates with dedicated DNS mapping.

Why Multiple Incognito Windows?

Incognito mode is a great way to open a clean browser session without carrying over cookies, cache, or other data from your primary browsing experience. However, opening multiple incognito windows in a standard configuration doesn’t isolate sessions—they share the same incognito context. This is where the --user-data-dir flag comes in.

By specifying a unique--user-data-dirfor each incognito session, you’re effectively sandboxing your browser profiles. This is particularly useful for:

  • Testing Multi-User Applications: Simulate multiple users interacting with your web application without needing separate devices or browsers.
    • Very useful, to have an regular user accessing the same application when simultaneously using an admin ID with the same application on the same MS Windows host.
  • Isolating Session Data: Prevent session contamination when testing login states, cookies, or caching behavior.
    • High value – we can effectively have multiple sessions to the SAME application.
    • This is very important benefit.
  • Debugging Environments: Configure distinct profiles for staging, production, or development environments.
    • So useful when working with IP addresses that are not in the production DNS and we do not have access to MS Windows host file to create aliases for the IP addresses during testing.

See below examples for three (3) commands with different user data directories that will ensure these browser sessions do NOT share a session or session cookies. We are no longer limited to a single incognito session!!! 

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" \
--incognito --user-data-dir="C:\Temp\ChromeSession1" https://www.example.com

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" \
--incognito --user-data-dir="C:\Temp\ChromeSession2" https://www.example.com

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" \
--incognito --user-data-dir="C:\Temp\ChromeSession3" https://www.example.com

Each session launched with a unique --user-data-dir path acts as a fully independent browser instance, complete with its own storage and settings. Chose a folder like C:\Temp where the Chrome browser will be able to create the data folder by itself and not impacted by any restrictive folder permission.

While we could run the above command line at will, however it may be more beneficial to store this string in the MS Windows shortcut, we can easily make as many Incognito sessions as we wish, attached to unique MS Windows shortcuts to the chrome.exe browser binary.

 

Managing TLS Certificates and DNS Mapping

When dealing with local development environments, you often need to work with IP addresses and TLS certificates. Usually you may have access to your local MS Windows host file, you can directly edit it to add the IP address with the hostname/FQDN that matches the CN (subject) or SANs of the TLS certificate.

However, if you do NOT have access to the MS Windows host file, usually we are stuck using the IP address in part of the URL and dealing with the TLS certificate warning messages. Chrome, by default, is strict about TLS and DNS, which can lead to frustrating “Your connection is not private” warnings. However, with a few additional flags, you can streamline this process.

DNS Mapping with Host Resolver Rules

The --host-resolver-rules flag allows you to map specific hostnames to IP addresses directly from the command line, bypassing the system’s DNS configuration. This is incredibly useful for testing domains that don’t have publicly resolvable DNS records or for redirecting traffic to a specific server in a development environment.

Example:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" \
--host-resolver-rules="MAP *.iam-dev.us 192.168.2.102" \
--incognito --user-data-dir="C:\Temp\ChromeSession" \
https://www.iam-dev.us:8444/sigma

This maps any subdomain of iam-dev.us to the IP address 192.168.2.102 without needing to modify your system’s hosts file. The additional benefit is that we can map the hostname to match the CN (subject) of the TLS certificate, so we do NOT see any TLS certificate errors.

We now have NO issue viewing a certificate that matched our hostname we provided in the shortcut to the Chrome browser.

Below is a live example testing with Symantec Identity Portal (IGA) solution, where we have two (2) separate incognito sessions, with different –user-data-dir to ensure we have isolated the sessions. We also have used the –host-resolver-rules with an IP address that is not in our DNS. We have mapped this IP address in the chrome shortcut.

Note: A “warning message” will show when we use the –host-resolver-rule flag, to ensure we are not being “hijacked” by someone else. Since we are doing this effort, you may click the “X” and close this warning message.

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --host-resolver-rules="MAP *.iam-dev.us 192.168.2.102" --incognito --user-data-dir="C:\Temp\ChromeSession"  https://www.iam-dev.us:8444/sigma  

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --host-resolver-rules="MAP *.iam-dev.us 192.168.2.102" --incognito --user-data-dir="C:\Temp\ChromeSession2" https://www.iam-dev.us:8444/sigma/admin

Handling Self-Signed Certificates

While the above worked for an environment with a proper TLS certificate, we need an alternative for environments using self-signed certificates, Chrome’s strict security measures can get in the way. Using flags like --ignore-certificate-errors (only in safe, controlled environments!) or configuring your system to trust these certificates can help.

Combined with the --user-data-dir option, you can even preload trusted certificates into specific profiles for a seamless workflow.

Here’s an example of a full command:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" \
--host-resolver-rules="MAP *.iam-dev.us 192.168.2.102" \
--incognito --user-data-dir="C:\Temp\ChromeSession" \
--ignore-certificate-errors \
https://www.iam-dev.us:8444/sigma

With this setup, you’re:

  • Running an isolated session with its own user data directory.
  • Redirecting specific DNS queries to a development server.
  • Accessing a self-signed certificate-protected URL without unnecessary interruptions.

Conclusion

By leveraging Chrome’s --user-data-dir, --host-resolver-rules, and other advanced flags, you can tailor your browser environment to handle complex workflows with ease. Whether you’re a developer, tester, or IT specialist, these tools offer a robust way to manage multiple configurations, ensuring efficient and error-free operations.

So next time you’re troubleshooting or testing, remember: the right Chrome flags can be game-changing. Experiment with these options and streamline your workflow today!

Bonus: View of active switches

Use chrome://version to view the active command line switches in use.