Coder Legion - Recent posts tagged github-pages

How a Dead Polyfill.io Link Got My Entire GitHub Pages Domain Flagged as Dangerous

Wed, 26 Aug 2026 04:47:00 +0000

I recently published a digital anthology project at nevmenandr.github.io/WLA.
The setup was smooth – I used Obsidian with the excellent
obsidian-publish-mkdocs plugin to generate a clean, documentation‑style site.

Everything worked beautifully… until Google Chrome started showing a bright red warning:
"Deceptive site ahead" – not just for my new project, but for every site hosted under my nevmenandr.github.io domain.

The Culprit: A Single, Innocent‑Looking Script Tag

While inspecting the generated HTML, I noticed lines where the polyfill.io link caught my eye. I tried visiting it directly (the full URL with /v3/polyfill.min.js?features=es6 on the polyfill.io domain).
Result: 401 Authorization Required – a dead service.

A Critical Red Flag: The Repository Is Stale

Digging deeper, I realised that the obsidian-publish-mkdocs repository on GitHub has not been updated for over two years.

This is a classic warning sign:

The plugin still bundles legacy dependencies that were once free but have since changed hands.
The maintainer hasn't patched or removed deprecated resources.
No security audits or dependency refreshes have occurred in that time.

While the tool works brilliantly out‑of‑the‑box, it's effectively unmaintained – and that's a risk you inherit as a user.

Why This Triggered Google's Safe Browsing

polyfill.io used to be a free, trusted CDN. But the domain was sold to a new owner who now requires payment and returns 401 (or even malicious redirects) for unauthenticated requests.

Google's crawler saw that my site included a script from a domain that now behaves suspiciously – and flagged the entire nevmenandr.github.io origin as a potential threat. This is a domain‑level penalty, meaning all my other GitHub Pages projects were blocked too.

The Fix: Step‑by‑Step Recovery Guide

If you ever face this, here's the exact process that got my site back online within ~24 hours.

1. Remove the Offending Resource

Locate and delete the problematic script tag from your HTML template.
In my case, I disabled the polyfill inclusion in the MkDocs theme config (or simply removed the line from the generated index.html).
Rebuild and redeploy your site to GitHub Pages.

2. Verify the Site is Clean

Visit your URL in a private/incognito window to confirm the red warning still appears (it will, until Google re‑crawls).
Use the Google Transparency Report tool (search for "Google Transparency Report" and then enter your domain in the Safe Browsing section) to check your domain's current status.

3. Claim Ownership in Google Search Console

Go to Google Search Console (search for it – it's Google's official tool for webmasters).
Add your site as a property (use the URL‑prefix type, e.g., https://nevmenandr.github.io/WLA/).
Verify ownership using the recommended method – for GitHub Pages, the easiest is:
1. Download the HTML verification file from Search Console.
2. Add it to the root of your repository (/path/to/your/repo/).
3. Commit and push – GitHub Pages will serve it automatically.

4. Request a Review

In Search Console, navigate to Security & Manual Actions → Security Issues.
If the warning is still active, you'll see a "Request Review" button.
In the review form:
- Explain clearly that you've removed the external resource that caused the issue.
- Mention that you've scanned your site for any other suspicious content.
- If you use any other external scripts, list them and confirm they are safe.

5. Wait (Usually 24‑48 Hours)

Google's team will review your request. In my case, the domain was cleared in about 24 hours.
You can monitor the status in Search Console – it will change from "Pending" to "Approved" or "Rejected".

Key Lessons for Developers

Third‑party scripts are liabilities. Always audit CDN links – especially free ones that can change ownership or monetisation models overnight.
Consider self‑hosting critical libraries or using well‑established CDNs with clear SLAs (e.g., cdnjs, jsdelivr).
Check the maintenance status of your tools.
A plugin that hasn't seen a commit in two years is a ticking time bomb. Always review the last update date before relying on any open‑source dependency in production. If it's stale, fork it, update the dependencies yourself, or look for an actively maintained alternative.
Google Safe Browsing penalises at the domain level.
A single compromised resource can take down all your sub‑projects, including unrelated ones. This is particularly painful on GitHub Pages where you share the *.github.io namespace.

Automate dependency checks.
Add a step in your CI/CD pipeline to test external URLs for HTTP 2xx responses. For example, with a simple curl check:

if ! curl -s -o /dev/null -w "%{http_code}" https://polyfill.io/v3/polyfill.min.js | grep -q "200"; then
  echo "⚠️  Polyfill.io is unreachable – aborting build"
  exit 1
fi

Know the recovery path.
Having a verified Google Search Console property is not optional if you publish public sites. It's your only channel to communicate with Google's security team when false positives occur.
Don't panic – the process works.
The warning looked scary, but the fix was straightforward. The key is to act quickly, be transparent in your review request, and double‑check that no other deprecated services remain.

Final Thought

Open‑source tools like obsidian-publish-mkdocs are brilliant for productivity – but they often bundle legacy dependencies for maximum compatibility, and when a repository stagnates for years, those dependencies can rot. As developers, it's our responsibility to review every external asset and check the pulse of our toolchain before going live.

One dead polyfill link and an unmaintained plugin cost me a day of heartache. Don't let it happen to you. 🚀

Weather Service Project (Part 2): Building the Frontend (GitHub Pages or Netlify and JavaScript)

Wed, 21 Jan 2026 06:44:50 +0000

In the first part of this series, we laid the groundwork for our global weather service. We built a Python script to fetch weather data from OpenWeatherMap, efficiently stored it in city-specific CSV files, and automated the entire collection process using GitHub Actions. Our "robot" is diligently gathering data 24/7.

But what good is data if you can't see it? Today, we shift our focus to the frontend: building an interactive, user-friendly dashboard that allows anyone to explore the weather data we've collected. We'll leverage the power of static site hosting with GitHub Pages or Netlify, use "vanilla" JavaScript to bring it to life, and rely on some excellent libraries for data handling and visualization. Let's make our data shine!

Free Web Hosting: GitHub Pages vs. Netlify

The first hurdle for any web project is hosting. Traditional servers can be costly and complex to manage. Following our "serverless and free" philosophy, both GitHub Pages and Netlify are perfect solutions for hosting static websites directly from your GitHub repository.

Option 1: GitHub Pages

GitHub Pages allows you to host static websites directly from your GitHub repository.

Activation is trivial:

Go to Settings > Pages in your repository.
Select your main branch (or the branch containing your web content) as the source.
Choose the /root folder (or a /docs folder if you prefer) as the location of your web files.
Click Save.

And just like that, your index.html file (and any linked assets) becomes publicly accessible at a URL like https://your-username.github.io/your-repository-name/. Simple, effective, and free!

Option 2: Netlify (the final choice for this project!)

For this project, I ultimately opted for Netlify due to its flexibility, ease of managing custom domains, and integrated continuous deployment. It also allows me to host the project directly under my Datalaria domain (https://datalaria.com/apps/weather/).

Steps to deploy on Netlify:

Connect Your Repository: Log in to Netlify. Click "Add new site" then "Import an existing project". Connect your GitHub account and select your Weather Service project repository.
Deployment Configuration:
- Owner: Your GitHub account.
- Branch to deploy: main (or the branch where your frontend code resides).
- Base directory: Leave this empty if your index.html and assets are in the root of the repository, or specify a subfolder if applicable (e.g., /frontend).
- Build command: Leave it empty, as our frontend is purely static with no build step required (no frameworks like React/Vue).
- Publish directory: . (or the subfolder containing your static files, e.g., /frontend).
Deploy Site: Click "Deploy site". Netlify will fetch your repository, deploy it, and provide you with a random URL.
Custom Domain (Optional but recommended): To use a domain like datalaria.com/apps/weather/:
- Go to Site settings > Domain management > Domains > Add a custom domain.
- Follow the steps to add your domain and configure it with your provider's DNS (by adding CNAME or A records).
- For the specific path (/apps/weather/), you would typically configure a "subfolder" or "base URL" within your application if it's not directly at the root of the domain. In this case, our index.html is designed to be served from a subpath. Netlify handles this transparently once the site is deployed and your domain is configured.

It's that simple! Each git push to your configured branch will trigger a new deployment on Netlify, keeping your dashboard always up-to-date.

The Frontend Tech Stack: HTML, CSS, and JavaScript (with a little help)

For this dashboard, I opted for a lightweight approach: plain HTML for structure, a bit of CSS for styling, and "vanilla" JavaScript (without complex frameworks) for interactivity. To handle specific tasks, I incorporated two fantastic libraries:

PapaParse.js: The fastest in-browser CSV parser for JavaScript. It's the bridge between our raw CSV files and the JavaScript data structures we need for visualization.
Chart.js: A powerful and flexible JavaScript charting library that makes creating beautiful, responsive, and interactive charts incredibly easy.

The Dashboard Logic: Bringing Data to Life in `index.html`

Our index.html acts as the main canvas, orchestrating the fetching, parsing, and rendering of weather data.

1. Dynamic City Loading

In stead of hardcoding a list of cities, we want our dashboard to automatically update if we add new cities in the backend. We achieve this by fetching a simple ciudades.txt file (containing one city name per line) and dynamically populating a <select> dropdown element using JavaScript's fetch API.

const citySelector = document.getElementById('citySelector');
let myChart = null; // Global variable to store the Chart.js instance

async function loadCityList() {
    try {
        const response = await fetch('ciudades.txt');
        const text = await response.text();
        // Filter out empty lines from the text file
        const cities = text.split('\n').filter(line => line.trim() !== '');

        cities.forEach(city => {
            const option = document.createElement('option');
            option.value = city;
            option.textContent = city;
            citySelector.appendChild(option);
        });

        // Load the first city by default when the page initializes
        if (cities.length > 0) {
            loadAndDrawData(cities[0]);
        }
    } catch (error) {
        console.error('Error loading city list:', error);
        // Optional: Display a user-friendly error message
    }
}

// Trigger city loading when the DOM is fully loaded
document.addEventListener('DOMContentLoaded', loadCityList);

2. Reacting to User Selection

When a user selects a city from the dropdown, we need to respond immediately. An addEventListener on the <select> element detects the change event and calls our main function to fetch and draw the data for the newly selected city.

citySelector.addEventListener('change', (event) => {
    const selectedCity = event.target.value;
    loadAndDrawData(selectedCity);
});

3. Fetching, Parsing, and Drawing Data

This is the central function where everything comes to life. It is responsible for:

Constructing the URL for the specific city's CSV file (e.g., data/Leon.csv).
Using Papa.parse to download and process the CSV content directly in the browser. PapaParse handles asynchronous fetching and parsing, making it incredibly easy.
Extracting relevant labels (dates) and data (temperatures) from the parsed CSV for Chart.js.
Crucial!: Before drawing a new chart, we must destroy the previous Chart.js instance (if (myChart) { myChart.destroy(); }). Forgetting this step leads to overlapping charts and performance issues!
Creating a new Chart() instance with the updated data.
Additionally, it calls a function to load and display the AI prediction for that city, seamlessly integrating it into the dashboard.

function loadAndDrawData(city) {
    const csvUrl = `datos/${city}.csv`; // Note the 'datos/' folder from Part 1
    const ctx = document.getElementById('weatherChart').getContext('2d');

    Papa.parse(csvUrl, {
        download: true, // Tells PapaParse to download the file
        header: true,   // Treats the first row as headers
        skipEmptyLines: true,
        complete: function(results) {
            const weatherData = results.data;

            // Extract labels (dates) and data (temperatures)
            const labels = weatherData.map(row => row.fecha_hora.split(' ')[0]); // Extract only the date
            const maxTemp = weatherData.map(row => parseFloat(row.temp_max_c));
            const minTemp = weatherData.map(row => parseFloat(row.temp_min_c));

            // Destroy the previous chart instance if it exists to prevent overlaps
            if (myChart) {
                myChart.destroy();
            }

            // Create a new Chart.js instance
            myChart = new Chart(ctx, {
                type: 'line',
                data: {
                    labels: labels,
                    datasets: [{
                        label: `Max Temp (°C) - ${city}`,
                        data: maxTemp,
                        borderColor: 'rgb(255, 99, 132)',
                        tension: 0.1
                    }, {
                        label: `Min Temp (°C) - ${city}`,
                        data: minTemp,
                        borderColor: 'rgb(54, 162, 235)',
                        tension: 0.1
                    }]
                },
                options: { // Chart options for responsiveness, title, etc.
                    responsive: true,
                    maintainAspectRatio: false,
                    scales: { y: { beginAtZero: false } },
                    plugins: { legend: { position: 'top' }, title: { display: true, text: `Historical Weather Data for ${city}` } }
                }
            });

            // Load and display AI prediction
            loadPrediction(city);
        },
        error: function(err, file) {
            console.error("Error parsing CSV:", err, file);
            // Optional: display a user-friendly error message on the dashboard
            if (myChart) { myChart.destroy(); } // Clear chart if loading fails
        }
    });
}

4. Displaying AI Predictions

The integration of AI predictions (which we'll delve into in Part 3) is also managed from the frontend. The backend generates a predicciones.json file, and our JavaScript simply fetches this JSON, finds the prediction for the selected city, and displays it.

async function loadPrediction(city) {
    const predictionElement = document.getElementById('prediction');
    try {
        const response = await fetch('predicciones.json');
        const predictions = await response.json();
        if (predictions && predictions[city]) {
             predictionElement.textContent = `Max Temp. Prediction for tomorrow: ${predictions[city].toFixed(1)}°C`;
        } else {
             predictionElement.textContent = 'Prediction not available.';
        }
    } catch (error) {
         console.error('Error loading predictions:', error);
         predictionElement.textContent = 'Error loading prediction.';
    }
}

Conclusion (Part 2)

We've transformed raw data into an engaging and interactive experience! By combining static hosting from GitHub Pages or Netlify, "vanilla" JavaScript for logic, PapaParse.js for CSV handling, and Chart.js for beautiful visualizations, we've built a powerful frontend that is both free and highly effective.

The dashboard now provides immediate insight into the historical weather patterns of any selected city. But what about the future? In the third and final part of this series, we'll delve into the exciting world of Machine Learning to add a predictive layer to our service. We'll explore how to use historical data to forecast tomorrow's weather, turning our service into a true weather "oracle." Stay tuned!

References and Links of Interest:

Complete Web Service: You can see the final project in action here: https://datalaria.com/apps/weather/
Project GitHub Repository: Explore the source code and project structure in my repository: https://github.com/Dalaez/app_weather
PapaParse.js: Fast in-browser CSV parser for JavaScript: https://www.papaparse.com/
Chart.js: Simple, yet flexible JavaScript charting for designers & developers: https://www.chartjs.org/
GitHub Pages: Official documentation on how to host your sites: https://docs.github.com/en/pages
Netlify: Official Netlify website: https://www.netlify.com/