Solved: Is it too much to be asked to not be advertised to in the portal?

🚀 Executive Summary

TL;DR: Internal IT portals often suffer from unwanted advertisements and promotional content, leading to reduced productivity, performance issues, and security risks. DevOps teams can resolve this by leveraging platform-native configurations, implementing client-side content filtering via proxies or managed browser extensions, or undertaking custom portal development for ultimate control.

🎯 Key Takeaways

• Platform-native configurations, such as removing or configuring widgets in ServiceNow or web parts in SharePoint, are the cleanest and most supported methods for eliminating promotional content directly at the source.
• Client-side content filtering, implemented through corporate proxies (e.g., Squid, PAC files) or managed browser extensions deployed via GPO/MDM, provides an effective alternative when server-side controls are insufficient, though it requires careful maintenance of blocklists.
• Custom portal development or deep modification of open-source solutions offers the ultimate control over content and user experience, ensuring complete absence of unwanted elements, but comes with higher initial development costs and significant ongoing maintenance overhead.

Unwanted advertisements in internal IT portals can significantly degrade user experience, reduce productivity, and even introduce security risks. This post details how DevOps teams can eliminate these distractions through strategic platform configurations, robust client-side filtering, or controlled custom portal development.

Symptoms: The Pain of Portal Advertisements

For IT professionals, the expectation for internal portals – whether for cloud management, monitoring, service desk, or knowledge bases – is focused efficiency. The intrusion of promotional content, even if it’s for “related services” or “new features” from the platform vendor, can manifest in several painful symptoms:

• Reduced User Productivity and Frustration: Every unnecessary visual element or clickable ad is a distraction from the primary task. Users often report feeling “spammed” even within their own work environment, leading to a negative perception of the tools. This isn’t just an annoyance; it’s a measurable drain on focus and efficiency.
• Performance Degradation: Advertisements often involve loading additional scripts, images, and tracking pixels. This bloat can slow down portal load times, increase network traffic, and consume client-side resources, directly impacting the responsiveness of critical applications.
• Security and Compliance Concerns: Third-party ad content can be a vector for supply chain attacks (malvertising) or privacy breaches. Even first-party “promotions” might rely on analytics or tracking scripts that fall outside an organization’s strict compliance policies for internal systems.
• Inconsistent Branding and Professionalism: Internal portals are an extension of an organization’s digital workspace. Advertising, especially if it doesn’t align with corporate messaging or aesthetics, can undermine the professional image and coherence of the internal ecosystem.
• Distraction from Critical Operational Data: In dashboards displaying metrics, alerts, or service health, promotional banners can obscure vital information or draw attention away from urgent operational statuses, leading to missed alerts or delayed responses.

Solution 1: Platform-Native Configuration and Policy Enforcement

The most direct and often preferred approach is to leverage the configuration capabilities of the portal platform itself. Many enterprise-grade SaaS solutions and cloud provider consoles offer administrative settings to disable promotional content, “What’s New” sections, or specific widgets.

ServiceNow Portal Configuration Example

For platforms like ServiceNow, administrators have extensive control over portal content. While specific “ad” toggles might not be explicit, features that act as promotions (e.g., “Trending Articles,” “Promoted Apps,” “What’s New”) can often be managed or removed.

• Remove or Configure Widgets: Navigate to the Service Portal designer. For any page, identify widgets that display promotional content. These might be “Announcements,” “Knowledge Base Featured Articles,” or custom widgets. You can often remove these widgets entirely or configure their options to only show specific, approved content.

Example: Removing a “News” widget from a custom portal page.

1. Navigate to Service Portal > Portals and open your target portal record.

2. Click on the “Open in Designer” button.

3. Select the problematic page (e.g., the index page or a custom landing page).

4. Locate the widget on the page. Hover over it and click the ‘X’ icon to remove it, or the pencil icon to configure its instance options (e.g., change the data source, disable promotions).

   • System Properties: Some promotional elements might be controlled via system properties. For instance, a hypothetical property like glide.service_portal.enable_promotional_banners could exist. Always consult the platform’s official documentation for specific properties related to UI elements.

SharePoint Online Portal Example (Microsoft 365)

SharePoint Online is widely used for internal portals and can often display “News,” “Highlights,” or “Recommended for you” web parts. While not strictly ads, these can be distracting.

• Remove or Configure Web Parts: Directly edit the page and remove or reconfigure the offending web part.

Example: Using PnP PowerShell to remove a “News” web part.

  # Connect to your SharePoint Online tenant
  Connect-PnPOnline -Url https://yourtenant.sharepoint.com/sites/yourportal -Interactive

  # Get the page where the web part resides
  $page = Get-PnPClientSidePage -Identity "HomePage.aspx"

  # Find the specific web part by its title or type (adjust as needed)
  # You might need to inspect the page or use Get-PnPClientSideWebPart to find the exact title or ID
  $newsWebPart = $page.WebParts | Where-Object { $_.Title -eq "News" }

  if ($newsWebPart) {
      # Remove the web part
      $page.RemoveWebPart($newsWebPart)
      $page.Save()
      $page.Publish()
      Write-Host "News web part removed from HomePage.aspx."
  } else {
      Write-Host "News web part not found on HomePage.aspx."
  }

This approach is generally the cleanest as it modifies the source content and doesn’t rely on client-side hacks.

Solution 2: Client-Side Content Filtering and Proxy Intervention

When server-side configuration isn’t possible or sufficient, client-side interventions can block advertisements before they reach the user’s browser. This typically involves corporate proxies or managed browser extensions.

Corporate Proxy/Firewall Rules

Organizations can use their existing network infrastructure to filter out known ad domains or URL patterns. This is effective for widely distributed ad networks.

• Implementing with Squid Proxy:

Define an Access Control List (ACL) for known ad-serving domains and deny access to them.

  # /etc/squid/ad_block_domains.txt (example content)
  # List of known ad domains to block
  ad.doubleclick.net
  ads.google.com
  cdn.ads.example.com
  metrics.vendor-portal.com # If a specific vendor metric/promo domain is intrusive

  # /etc/squid/squid.conf (configuration snippet)
  # Define an ACL for advertisement domains
  acl ad_domains dstdomain "/etc/squid/ad_block_domains.txt"

  # Deny access to these domains
  http_access deny ad_domains

  # Ensure other rules allow legitimate traffic
  http_access allow localhost manager
  http_access deny manager
  http_access allow localhost
  http_access allow all

Restart Squid after modifying the configuration.

• PAC (Proxy Auto-Configuration) Files: Distribute a PAC file via Group Policy or MDM to all corporate browsers. The PAC file can instruct browsers to route specific domains through a blocking proxy or directly block them.

  // proxy.pac example
  function FindProxyForURL(url, host) {
      // List of known ad domains
      var adDomains = [
          "ad.doubleclick.net",
          "ads.google.com",
          "cdn.ads.example.com"
      ];

      for (var i = 0; i < adDomains.length; i++) {
          if (dnsDomainIs(host, adDomains[i]) || host == adDomains[i]) {
              return "PROXY 127.0.0.1:9999; DIRECT"; // Effectively blocks by sending to a non-existent proxy
          }
      }

      // Default: use the main corporate proxy
      return "PROXY corp-proxy.example.com:8080";
  }

This PAC file would then be pushed to client browsers, making them consult this logic for every request.

Browser-Level Solutions (Managed Extensions & Group Policies)

For browsers like Chrome or Edge, IT can deploy specific ad-blocking extensions via Group Policy Objects (GPO) or Mobile Device Management (MDM) solutions like Microsoft Intune.

• Deploying via Chrome GPO (ExtensionInstallForceList):

This GPO setting forces the installation of specified extensions and prevents users from disabling them. You would typically use an enterprise-grade content blocker rather than a consumer ad-blocker due to trust and support.

Example (for a hypothetical content blocker with ID ‘abcdefghijklmnopqrstuvwxyz’):

  # Registry path for Chrome GPO
  # HKLM\SOFTWARE\Policies\Google\Chrome\ExtensionInstallForceList

  # Value: 1 (REG_SZ)
  # Data: abcdefghijklmnopqrstuvwxyz;https://clients2.google.com/service/update2/crx

• Considerations: While effective, this approach can sometimes break legitimate website functionality if the ad-blocker is too aggressive. It requires ongoing maintenance of blocklists by the extension vendor or custom rules by your IT team.

Comparison Table: Proxy Blocking vs. Browser Extensions

Feature	Corporate Proxy/Firewall Blocking	Managed Browser Extensions
Granularity	Domain/URL path level. Less granular for specific elements within a page.	Element-level blocking (CSS selectors, JavaScript). Highly granular.
Deployment	Network-wide via proxy configuration; applies to all HTTP/HTTPS traffic.	Browser-specific via GPO/MDM; only applies to managed browsers.
Maintenance	Requires maintaining custom blocklists on proxy/firewall.	Relies on extension vendor updates for blocklists; custom rules are possible.
Performance	Minimal overhead on client; processing occurs at the proxy/firewall.	Can introduce client-side overhead as the browser processes DOM and scripts.
Potential Impact	Lower risk of breaking legitimate page functionality, but can block entire sites.	Higher risk of breaking specific page elements or functionality due to aggressive DOM manipulation.
Visibility	Traffic logs at proxy/firewall show blocked attempts.	Less central visibility into what’s being blocked on individual clients.

Solution 3: Custom Portal Development and De-branding

For organizations with unique needs or a strong desire for ultimate control, building a custom internal portal or heavily modifying an open-source solution offers the most comprehensive way to eliminate unwanted content.

Building a Bespoke Internal Dashboard (e.g., using React, Vue, or Python/Flask)

By developing a portal from scratch, you dictate every element and integration. Tools like Grafana, Kibana, or custom web applications (built with frameworks like React, Vue.js, Angular, or backend frameworks like Flask, Django, Node.js) provide this flexibility.

• Complete Content Control: You integrate only the APIs and display only the data that is relevant to your operations. There are no third-party scripts or vendor-promoted content unless explicitly added.

Example: Removing a “PromoBanner” component from a React-based custom portal.

If your portal is built with React, you might have a component structure like this:

  // src/components/Layout/MainLayout.js
  import React from 'react';
  import Header from './Header';
  import Footer from './Footer';
  // import PromoBanner from '../Marketing/PromoBanner'; // <-- This line would be removed

  const MainLayout = ({ children }) => {
      return (
          <div className="app-container">
              <Header />
              {/* <PromoBanner />  <-- This component instance would be removed */}
              <main className="app-content">
                  {children}
              </main>
              <Footer />
          </div>
      );
  };

  export default MainLayout;

By simply commenting out or deleting the import and the component instance, you ensure it’s never rendered.

Modifying Open-Source Portal Solutions

If you’re using an open-source portal (e.g., custom Kubernetes dashboard, Jenkins UI, custom Grafana dashboards via templating), you can often fork the project and modify its source code or templates to remove unwanted elements.

• Templating Engine Example (Jinja2/Flask):

If your portal uses a templating engine, you can edit the HTML templates directly. For instance, to remove a promotional div from a Jinja2 template:

Original template (base.html):

  <!DOCTYPE html>
  <html>
  <head>
      <title>My Internal Portal</title>
  </head>
  <body>
      <div id="header">...</div>
      <div id="promo-banner">
          <p>Check out our new feature!</p>
          <!-- Or includes a macro/component for ads -->
          {% include 'marketing_module.html' %}
      </div>
      <div id="content">
          {% block content %}{% endblock %}
      </div>
      <div id="footer">...</div>
  </body>
  </html>

Modified template (removing the promo banner):

  <!DOCTYPE html>
  <html>
  <head>
      <title>My Internal Portal</title>
  </head>
  <body>
      <div id="header">...</div>
      <!-- <div id="promo-banner">
          <p>Check out our new feature!</p>
          {% include 'marketing_module.html' %}
      </div> --> <!-- Commented out or removed entirely -->
      <div id="content">
          {% block content %}{% endblock %}
      </div>
      <div id="footer">...</div>
  </body>
  </html>

• Pros: Ultimate control over the user experience, tailored functionality, complete absence of unwanted content.
• Cons: Higher initial development cost, significant ongoing maintenance overhead (security patches, feature updates), requires dedicated development resources, and potentially diverges from upstream open-source projects (making updates harder).

Conclusion

The request to not be advertised to in an internal portal is not “too much” – it’s a legitimate concern for maintaining a professional, productive, and secure work environment. DevOps teams, leveraging their understanding of both infrastructure and application development, are uniquely positioned to address this.

A phased approach is often best:

1. Start with Platform-Native Configurations: Always explore administrative settings first. These are typically the cleanest and most supported methods to control content within a given SaaS or PaaS platform.
2. Layer Client-Side Filtering as Needed: If platform controls are insufficient, deploy corporate proxy rules or managed browser extensions for a network-wide or browser-specific content blocking. Be mindful of potential side effects and maintenance.
3. Consider Custom Development for Ultimate Control: For critical internal tools or when an exceptional user experience is paramount, investing in custom portal development or deep modification of open-source solutions offers unparalleled control, albeit with higher resource demands.

By proactively managing portal content, IT professionals can significantly enhance user satisfaction, improve operational efficiency, and uphold the security and professionalism expected of modern digital workspaces.

---

👉 Read the original article on TechResolve.blog