Trailhead Tracker - Update 2 - What are CORS Errors?!

I’ll admit, after the chaotic fiasco that marked day one of this project, I took a step back. Actually, it was more than just a step—I fell into a bit of a slump. My hobbies, usually my sanctuary, became background noise as I spent more time than usual sleeping and avoiding my usual routines.

To be clear, this project wasn’t the cause of my mental state—it just happened to coincide with one of life’s perfectly inconvenient timings. You know, those moments that make you question if it’s all “just a coincidence.” As I sit down to reflect, I realize that some of the details of what I’d call "Phase 2" of the project are a little fuzzy. But what I do remember is that this project became something more than just a technical challenge. It became a journey—a mix of setbacks, victories, and more learning than I expected.

A Fleeting Victory

After hours of troubleshooting, I finally managed to get a 200 OK response using Postman. It felt like the project was finally clicking into place. The logic worked; the API was responding, and all that was left was to integrate it with my website. It seemed like a straight shot to the finish line.

Then came the errors. No matter how I tweaked the setup, my attempts to fetch data from the API through my website kept failing. Each request was met with a cryptic message in the browser's developer console: CORS error.

I had never encountered this issue before and didn’t know what it meant. A quick web search introduced me to CORS, or Cross-Origin Resource Sharing. Essentially, CORS is a browser-enforced policy designed to block requests from unknown or untrusted sources. It turns out the Trailhead API restricts API calls from domains it doesn’t explicitly trust, which is a common security measure to prevent unauthorized use or abuse of their resources. Suddenly, my seemingly straightforward project turned into a much bigger challenge.

How do I proceed?

After researching potential solutions, I found one approach that was widely recommended: setting up a proxy server. The concept made sense after some reading, but at the time, it felt like I was venturing into uncharted waters.

I still didn’t fully grasp why this worked, but I was determined to make it happen. My understanding of CORS and proxies at the time was rudimentary at best, but it’s incredible how much more I’ve learned over the past week. After evaluating my options, I decided to use AWS Elastic Beanstalk for the proxy. I already had some exposure to AWS, and I figured the extra experience would be an asset in itself.

My First Time Managing a Server

Setting up the server was an adventure in its own right. Elastic Beanstalk simplified some of the deployment processes, but there was still plenty of work to be done. From Flask configuration to Nginx, I encountered problems that made me question my entire approach. There were permissions to manage, routing issues to resolve, and constant debugging.

Early on, I identified a critical security oversight: the security group attached to my instance was open to all inbound traffic on port 22. This was a glaring vulnerability, essentially leaving the door wide open for unauthorized SSH access. While no system is ever completely impervious to penetration, this was an obvious risk that needed immediate attention. I restricted access, implemented MFA for AWS, and reviewed other configurations to ensure the environment was as secure as possible without hindering its functionality.

After nearly seven hours of setting up Elastic Beanstalk, debugging, and verifying configurations, it was finally time to query Trailhead through the proxy. I was optimistic, but the query failed miserably. Completely stumped, I turned to ChatGPT for help. Within minutes, it identified the root cause: my proxy was using an unsecured protocol (HTTP on port 80), whereas Trailhead and my domain required HTTPS. This mismatch in protocols—known as "mixed content"—was blocking the request.

"Great—another roadblock!" I thought. But this one, like the others, became an opportunity to learn and improve.

The Final Step?

All that was needed was to request an SSL certificate for my proxy through AWS. While this didn't seem too difficult (And it wasn't), I had already felt so overwhelmed with all of the new concepts and tools. I was at the end of my rope, and called it a night after the request was approved and attaching the certificate to my proxy. I didn't even want to test it, for fear that I would find even more work to do.