Posts tagged "authentication"

Testing Private Content with BrowserLab

Testing Private or Local content in BrowserLab

A recurring question we get on the BrowserLab User Forums is “How can I test pages that I have on my local machine and/or behind my firewall?”

A public URL is normally necessary because BrowserLab generates screen shots by visiting the page and taking snapshots of it in the actual browser. There are, however, three alternative methods for using BrowserLab that will allow you to test pages that are not publicly available.

BrowserLab for Firebug

The most versatile option is to use the BrowserLab for Firebug add-on for Firefox. Currently the BrowserLab for Firebug add-on supports Firefox versions 3.x to 6.x and will be extended as new versions of Firefox are released. For our add-on to work, you must have the correct versions of Firefox, our add-on and Firebug installed. Fortunately, Firefox does a really good job of helping you stay current and in sync.

The BrowserLab for Firebug add-on allows you to test private content by selecting the “Preview Local Source” option from the BrowserLab for Firebug menu in Firefox. You can also test publicly available content by selecting “Preview URL,” which simply sends the current URL to BrowserLab. When you choose the “Preview Local Source” option the add-on uploads the HTML content and assets from your machine to a private directory on Adobe’s servers, which only BrowserLab has access to. Once the files are uploaded, BrowserLab can take screen shots from that secure server. Please note, you must select the Options menu item and ensure that the read-only permission option has been set to “Allow.” You are able to test private websites and intranet pages by first navigating to the page in your browser and entering any username/passwords, once you choose “Preview Local Source” the local content from your browser is uploaded and screen shots are generated.

For more information on the precautions taken to ensure content uploaded to Adobe’s secure server for screen shots is inaccessible to any other user, please read our tech note.

Because the page is running in your Firefox browser, this also allows for some limited interactive testing of your pages. For example, if you have dynamic menus, dropdowns or similar elements on your page, you can select the “Freeze JavaScript” option, interact with your page to display those elements, and then request screen shots of the page in that state either by selecting the “Preview Local Source” menu option or pressing the hotkey combination for it (Ctrl-Shift-F12 in Windows, Command-Shift-F12 on Mac OS X)).

When using Preview Local Source, another option to be aware of is the “Preserve CSS Hacks” setting. When a website uses a browser-specific CSS hack that Firefox doesn’t recognize, it is stripped out of the final page displayed in Firefox. Since “Preview Local Source” uploads the content that is currently in your browser, it can cause previews of the page in other browsers to display incorrectly if non-Firefox hacks specific to those browsers were removed. The “Preserve CSS Hacks” can fix this by merging those missing hacks back into the content that is uploaded to our servers for testing.

Please note, the purpose of this post isn’t to cover every possible situation you can run into, but if you’re having problems getting “Preview Local Source” to work correctly, make sure to check the “Freeze JavaScript” and “Preserve CSS Hacks” options, and try bumping up the screen shot Delay setting to allow more time for the page to finish loading before screen shots are captured.

If you’d like to see all of this in action, watch our BrowserLab for Firebug video on AdobeTV.

BrowserLab for Dreamweaver

If you use Dreamweaver CS5 or CS5.5 you can test private content using the BrowserLab for Dreamweaver extension, which is included in the product.

To begin, you should first ensure that you have the most up-to-date version of Dreamweaver by choosing Help > Updates from the menu and installing any available updates. Once you have finished updating (and restarting your computer if needed), open the BrowserLab panel by choosing Window > Extensions > Adobe BrowserLab from the Dreamweaver menu. You can use the dropdown control in the panel to switch between testing private (“Local/Network”) content and public (“Server”) content. This blog post will only focus on testing private content.

The extension allows you to test private content by creating a secure tunnel between your network and a private directory on Adobe’s servers, which only BrowserLab can access and take screen shots from. (See Data Privacy Concerns, above, for more information about how your data is kept private.) For this to function properly you should have a site set up within Dreamweaver (Site > Manage Sites) with the Local Site Folder field pointing to the root of your local site. Next, in the BrowserLab panel, select the list icon to open the extension menu, choose “Permission Settings”, and make sure the Allow option is selected. These two settings allow the BrowserLab for Dreamweaver extension to know the location of your pages and related assets, and will permit it to upload them to Adobe’s servers.

We’ve taken every precaution to keep your data safe, secure, and inaccessible from any other user. If you are still concerned about the security of your files when uploading them to BrowserLab, please take a look at our tech note on this subject.

Once you’ve followed these steps, activate the site you want to test in Dreamweaver by selecting it from the Sites menu in the Files panel. When the page you want to test is displayed, select the Preview button in the BrowserLab panel. Your page and all necessary assets will be uploaded to our servers, BrowserLab will open in your default browser, and screen shots will be returned (you’ll be asked to log in if BrowserLab was not running already). In addition to allowing you to test your local pages, this integration allows you to test interactive states of the page such as rollovers and tabs by switching to Live View in Dreamweaver, interacting with your page, choosing Freeze JavaScript to freeze the page state, and then clicking the Preview button in the BrowserLab panel to generate screen shots for that state in all your selected browsers.

If you’d like to see BrowserLab for Dreamweaver in action, watch our BrowserLab for Dreamweaver video on AdobeTV.

Allow BrowserLab Egress IP access

The final option for testing private content with BrowserLab is simply to allow BrowserLab to direct access to your content by granting permission to BrowserLab’s egress IP addresses. You can find more details in our blog post covering this topic. To reiterate our warning from that post – If you have confidential information then it may be best not to use this method for testing secure content, or to only allow our IP addresses access while you are actively testing. The primary reason for port forwarding would be if you have a webserver at home or in a small office and don’t have access to a staging server on the Internet. In most cases, this should not be done unless you know what you are doing.


BrowserLab is a versatile and easy to use testing tool to help you achieve cross-browser consistency and can be used with private, local and public content. It is fast and secure, and takes the hassle out of cross browser testing. Once you start using it, you might wonder how you ever got along without it.

Mark Rausch
BrowserLab Engineer

BrowserLab Egress IP Addresses

The current public egress IP address for the BrowserLab service is:

(Updated August 28, 2012)

These addresses are subject to change, but we will try to keep this blog post updated with the latest changes.

What are the egress IP addresses and why should you care? When you ask BrowserLab to return screen shots for a url, our servers will make the request from one of these two addresses. Users of BrowserLab can take advantage of this information in a few different ways:

First, since a single test run from BrowserLab could result in almost 20 visits to the page, you might decide you want to exclude BrowserLab visits from your site analytics. Most analytics tools will allow you to list individual IP addresses or a range of addresses to ignore.  Here are some examples for Google Analytics and WebTrends.

Second, since BrowserLab will make so many simultaneous requests for your page, it can sometimes be mistaken as an attack by some pieces of hardware or software. To avoid this, you can put our egress IP addresses in as trusted IP addresses that can safely be ignored.

Third, you can use the IP addresses to exempt BrowserLab from some types of password protection you can set up for your web pages. For example, you can use the htaccess configuration file in Apache to password protect a site from the general public, but configure the htaccess to allow BrowserLab access without a password.

Finally, you can use the IP addresses to allow BrowserLab to reach through your firewall to get screen shots for pages it couldn’t otherwise get to. Port forwarding allows you to access a machine behind the Firewall at a specified port. For instance you could have your firewall  direct public traffic on port yourIP:9999 to port 80 on an internal webserver. By limiting access to the BrowserLab servers, you are limiting the exposure to the outside world. The risk in doing this is that another BrowserLab user could guess that you’ve done this and submit URLs that they think are internal to your network. If they guess correctly, they will get screen shots of the pages that they correctly guess. The other risk is that you do something wrong and open an internal machine to the internet. If you have confidential information then it would be best not to use this method for testing secure content or to only allow our IP addresses access while you are actively testing. The primary reason for port forwarding would be if you have a webserver at home or in a small office and don’t have access to a staging server on the internet. In most cases, this should not be done unless you know what you are doing.

If you want BrowserLab to be able to access your pages behind a firewall, we recommend that you either talk to a knowledgeable person in your IT department or, if you are without an IT department, here are some links with instructions on how to set up port forwarding for some of the more common routers: Netgear informationLinksys information.

A full discussion about port forwarding is outside the scope of this blog post since the process can vary widely from router to router. It can help to have a friend from outside your network try and access the content you want to test (just make sure to add their IP address to your whitelist). If your friend can’t get to your content, the BrowserLab servers won’t be able to either. If you find yourself having difficulty getting it to work, your best bet is to consult the documentation for your own hardware or contact a qualified IT support person.

As I said above, these egress IPs are occasionally subject to change. We’ll do our best to keep this post updated with the latest IPs and are also considering ways to make finding the current ones more convenient. For now, if you want to ensure you have the correct IP address, you can determine that by submitting as a URL to BrowserLab. The returned screenshot will show our current egress IP.

Mark Rausch
BrowserLab Software Developer