Non-Production IP Restrictions

This guide discusses what Non-Production IP Restrictions are, why they’re being put into place service-wide, how they might impact how you develop your sites, and how to make sure your sites are ready for their implementation.

What is Changing?

Web Services, in an effort to improve security and reduce unintended discovery of content before it’s Production-ready, has been gradually moving to block off-campus access to non-Production (Test, Development, and QA) websites except where it is strictly needed. This is being done by restricting access to those sites to just those IP (Internet protocol) address ranges that correspond with Purdue campus, wireless, and virtual private networks. So far, this restriction has enabled for environments as they were replaced, but since we’re down to just one main environment (the PPWC, or Primary Purdue Web Cluster), we’re making one final push to enable this security everywhere.

Once fully enabled, non-Production versions of all websites that don’t need an exception will only be accessible from Purdue campus networks. In this case, “campus networks” includes all Purdue campuses, the PAL wireless network both on and off campus, and both general purpose and off-campus-specific Purdue VPNs.

For the most part, this has already changed for over half the websites Web Services hosts. However, since the PPWC is our largest platform with the most developers, we are taking care to make this transition as painless as possible.

Why is It Changing?

By blocking access to non-Production (Test, Development, and QA) websites from off-campus, Web Services aims to do two things:

  • Improve security of code before it has been fully validated and deployed to Production.
    • Sites that contain active code need to go through a security review before they are Production-ready.
    • Restricting access to sites before they’ve been through this process ensures that code that isn’t Production ready can’t be accessed by off-campus attackers.
  • Prevent non-Production sites from showing up in public search results.
    • While robots.txt files ask web crawlers not to index non-Production sites, they don’t actually prevent this from happening.
    • By preventing indexing of non-Production sites, only your Production sites will show up in search results.

How Will It Affect Me?

For most sites it won’t have any impact. Not only do most sites already have this restriction, but web developers already need to be on a Purdue network to upload files to Development web servers. There are a couple of instances where developers may notice an impact, however:

  • Cascade users can currently access the Cascade CMS from off campus without a VPN. However, after this change Cascade users won’t be able to test pages after publishing with Cascade or view live previews within Cascade without being on a campus network. This is an expected side-effect, and Web Services recommends always being connected to a Purdue VPN when working remotely on web development unless you are specifically testing your site from off-campus.
  • Some sites contain pages that directly reference Development content from Production due to coding mistakes. For example, a Production page may have an image or stylesheet loading from Development. In these cases, the Production web page will “break” for off-campus visitors after non-Production sites are restricted to campus networks only. Web Services is working with the owners of these sites to make sure they’re ready before this change occurs.

If you’ve been sent a link to this page because you are listed as owner of one or more pages potentially impacted by the second point above, or you’ve found that one or more of your Production pages is no longer displaying properly when viewed from off-campus, please continue reading for what you and/or your site developers need to do to correct the problem.

What is Web Services Doing to Prevent Issues?

To reduce or eliminate the impact of this change, we have done and will do the following:

  1. We have run a scan of all files on the PPWC looking for what appear to be inadvertent references to Development sites and matched those up with primary contact information.
  2. We have contacted the primary (and, if needed, any secondary) contacts for each site with identified potential issues so any problems can be corrected before they break site presentation. These notices will begin going out on Monday, September 19, 2022.
  3. We will provide a “test day” on Thursday, October 7, 2022 (starting at 9 AM Eastern) where we will temporarily enable these restrictions so site developers can directly see if anything has been missed and validate that fixes worked. A quick scan looking for non-Production references in Production pages will be run just before this date to ensure no high traffic pages will be impacted.
  4. After leaving about a week for site developers to correct any lingering issues, we will produce another report of files with potential issues, removing any false-positives identified and reported by developers in step 2. If any issues remain, we will contact those site owners again with the final potential issues that need solved.
  5. Finally, on Thursday, October 27, 2022, Web Services will restrict access to non-Production sites to Purdue campus addresses only across the board.
  6. A mechanism has been created to allow per-site or even per-directory temporary (or, where warranted, permanent) exemptions to this restriction. For example, to allow testing of a site in QA from off-campus, or to allow a non-Production site to test integration with an external vendor’s test environment. Such exemptions can be requested by contacting Web Services.

What Do I Need to Do?

Depending on how you are affected (see above), you may need to make some changes in either how you work on your sites or some changes to your sites themselves.

Cascade Users

Developers using Cascade to edit their sites should follow the following checklist to make sure they aren’t impacted by non-Production IP restrictions:

Developers Who Were Notified of an Issue

If you’re reading this page because you were notified of a potential issue with one or more pages on sites that you own once these IP restrictions go live, you’ll want to follow this checklist for every file reported:

  1. Open the file in question and search for references to “dev.www.purdue.edu” and your site’s Development host name if it’s not dev.www.purdue.edu. For example, for www.admissions.purdue.edu, you’ll want to search for both dev.www.purdue.edu and dev.admissions.purdue.edu.
  2. Check to see if those references are intentional or if they need to be corrected. That is, it’s safe to eliminate cases where you intentionally refer to a Development website in a comment, where you programmatically select content based on the site tier or host name, or when a file is Development-only and isn’t intended to be deployed to QA or Production.
    1. Intentional references can be ignored. Please note which files have them and reply to the message you received about checking the files to indicate you’ve reviewed the files and found nothing that needs changed. We’ll eliminate those from our next check-up prior to enabling these restrictions.
    2. For intentional references that should stay in Development and not be deployed to QA or Production, please consider asking Web Services to enable an exclusion to prevent accidental deployment if you don’t have one already.
    3. Everything else needs to be corrected, so continue with step 3.
  3. Make changes to site files that improperly references Development. This usually involves:
    1. Converting absolute urls to relative or site-relative urls wherever possible.
    2. In some cases, relative URLs won’t work, but you can use PHP (or ASP, or .NET) to choose the correct URL for your site every time a page loads by checking the value of the TIER environment variable.
    3. Wherever the above aren’t possible, change all references to your site’s URL to use your site’s Production URL prior to deploying your site to Production.
  4. Test that your changes work in your Development site.
  5. Deploy your changes to QA and validate that they still work there.
  6. Deploy your changes to Production. If you do this prior to Thursday, October 6, 2022, you will be able to test that your fixes worked on the test day.

How Do I Test My Site?

There are four main ways to test that your site won’t have issues with non-Production IP restrictions: Checking for direct references in files (which we also do for you), checking your browser’s developer tools, testing your site from an off-campus network while the restrictions are in place, or using a tool like SiteImprove after the IP restrictions are in place.

Checking for Direct References

Web Services is already doing this for you and notifying you when we find issues, but there are some issues we can’t catch:

  • Values stored in databases that, when evaluated by your site code, directly reference Development or QA pages from Production.
  • “Minified” JavaScript and CSS can be very difficult to reliably test for non-Production references without including false-positives. Checking the original, non-minified sources is useful.

As a result, we recommend you check your own site code as well for direct references to your non-Production site URLs that would end up getting used in Production, then correct those references as shown above.

Using Browser Developer Tools

All modern browsers are a little different in how they present developer tools and what tools are available, but all offer something that will help point out pages that reference non-Production resources referenced by Production. As a bonus, this works both on and off-campus as well as before and after this change is put into place. Try the following:

  1. Visit the Production version of the page you’d like to test in your browser. Note that this can be done from a desktop or laptop as written. It’s also possible to test from a mobile device alongside a desktop or laptop, but that won’t be covered here.
  2. If you’re using Windows, press F12. If you’re using macOS, press command+option+i. This will open the developer tools regardless of browser and regardless of what your browser calls them.
  3. If your browser’s developer tools have a “Sources” tab (most do), that’s the best one to use here. Make sure to group “By Path” if given the option. Note that Firefox puts Sources under the Debugger tab, but it’s the same thing.
  4. Collapse the tree view if needed under Sources so you just see the top-level domains. Do you see any Development (or Test or QA) domains? For example, if your site is on www.purdue.edu, do you see dev.www.purdue.edu in this list? If so, you’ve got non-Production references that need fixed! In this example, you could expand the dev.www.purdue.edu entry fully to see what’s being included from Development, then search through your page’s source code to find where that needs changed.
  5. Another developer tools tab that’s somewhat useful here is the Network tab. You may need to refresh the page after selecting the Network tab if it doesn’t show anything. One of the columns shown is domain, and you should be able to click on that to sort by domain. That will let you look for any parts of the page that are coming from a non-Production domain so you can see what references need updated. This can also be used after non-Production IP restrictions go live to quickly spot errors caused by referencing non-Production from a Production page (see below).
  6. Repeat the test on other pages of interest, or even your whole site.
  7. Once you’ve identified what fixes need made, make those fixes, publish them, verify they work in QA, and deploy them to Production.
  8. If this is done on or before the test day on Thursday, October 6, 2022, Web Services will reach out shortly thereafter with any pages that still have potential issues we are able to identify. You may also wish to test again yourself on the test day or after restrictions are permanently in place.

Testing From Off-Campus

Either on Thursday, October 6, 2022 (the test day), or after Thursday, October 27, 2022 when the restrictions will remain in place, you can also test your pages from off-campus to quickly spot issues. But how to test from off-campus?

  • Obviously, if you’re working remotely, just turn off your VPN or use a different computer that isn’t connected to the VPN. Make sure you’re not on PAL 3.0, since that also counts as on-campus even if you’re connecting from downtown Lafayette or other extended PAL service areas.
  • If you’re on-campus and your computer has Wi-Fi, connect to the attwifi network which is treated as off-campus.
  • If you have a mobile device with cellular tethering or a Mi-Fi, join its network from your computer and you’ll be treated as off-campus even if physically on campus.
  • If none of these options apply, see the browser developer tools method shown above to spot non-Production references.

Great, now you can view your site from off-campus, and it’s either Thursday, October 6, 2022 or after Thursday, October 27, 2022. Really important items, like a header image or a primary stylesheet being referenced from Development by Production will stick out like a sore thumb: your Production page will appear broken or have missing images. But how to make sure you haven’t missed something small? Your browser’s developer tools can help here too:

  1. Load the Production page you want to test from an off-campus network when non-Production IP restrictions are in place.
  2. Press F12 on Windows machines or command+option+i on Macs to launch your browser’s developer tools.
  3. Find the Console tab. Your browser may even show warning (yellow triangle) and critical (red stop sign) error badges that will link you directly there if clicked.
  4. We’re interested in errors here, so if your browser’s Console lets you hide warnings, that can help. Do you see error messages about not being able to load a resource from a Development site because of a 403 error? That’s something that will need fixed. You can usually even click on the error to be taken to the spot in your page code where the reference will need fixed.
  5. Beyond the Console tab, the Network tab is also useful. You may need to refresh the page when you first select the Network tab, but this will show each item that’s loaded, where it came from, and if an error was encountered, usually highlighting those items with errors. Again, you’re looking for 403 errors with items coming from a non-Production website.
  6. Find and note the corrections you need to make.
  7. Repeat testing with each page you need to test.
  8. Make, publish, test, and deploy your corrections.
  9. If this was done on the test day (Thursday, October 6, 2022) Web Services will reach out shortly thereafter with any pages that still have potential issues that we are able to identify.

What if My Non-Production Site Needs to be Accessible from Off-Campus?

While it is rare that a non-Production site would need to be accessible from off-campus, Web Services has planned for the possibility. Both temporary and permanent exceptions can be requested. To request an exception, simply open a ticket with Web Services indicating the URL that needs the exception, the duration of the exception, and the reason for the exception. Details about the types of exceptions that can be requested follow.

Automatic Exceptions

While most sites have only a handful of pages to fix so they don’t reference non-Production content from Production, a few sites have hundreds and hundreds of pages to fix. These sites will be given an automatic temporary exception and a separate deadline, negotiated individually, for their non-Production pages to be restricted to Purdue campus networks only.

Additionally, some sites on platforms that already have non-Production sites restricted to campus networks have pre-existing exceptions. Those exceptions will remain in place.

Temporary Exceptions

The most common exception request is for a non-Production site (usually QA) to be made accessible from off campus for a set period of time while it’s being tested or evaluated by someone outside of Purdue. This could be a team at another university that’s collaborating with you, an automated scanning tool run by an off-campus service, or just some people testing in the field that don’t have a usable VPN app on their mobile platform.

Another somewhat common request is a temporary exception allowing access to a Development and/or its corresponding QA site when getting help from a software or service vendor to troubleshoot an issue. While it is best security practice to have the external developer or vendor connect through a local developer’s workstation via screen sharing, sometimes the vendor needs specific tools that only they have available. Note that the last example also requires an exception from Security.

Permanent Exceptions

Permanent exceptions are rare, but do on occasion need to exist. The most common of these is when a vendor also offers both Production and non-Production versions of their platform and their non-Production platform needs to directly communicate with a non-Production site. Another example would be a Purdue developer using a development tool that’s hosted off-campus that needs to connect with their development site (usually via an API) directly.

In all cases, a permanent exception should be limited to a narrow list of off-campus IP addresses that can communicate with the non-Production site. In the examples above, that would be the IP address or address range for the external tool or vendor platform.

Cases That Do Not Need Exceptions

There are many situations where accessing a non-Production site from off campus is needed but doesn’t require an exception to allow direct access from all or some off-campus networks:

  • An off-campus developer must have a Purdue account to develop Purdue sites (even if they work for an external vendor), and so must connect to a Purdue VPN while working remotely. While connected to the VPN, the developer is effectively on the Purdue campus network.
  • Cisco AnyConnect is available for iOS, Android, and even the discontinued Windows Mobile platform, so off-campus testing from a mobile device should not require an exception if a VPN can be used.
  • It is security best practice that vendors connect through a local developer’s workstation via screen sharing with the local developer present when working on Purdue-hosted sites and applications. So long as said Purdue developer’s workstation has the tools required to troubleshoot the problem (or they can be installed) or the necessary data can be sent to the vendor for local analysis, this doesn’t require an exception.