search

freeCodeCamp / demo-projects

Example certification projects for our programming curriculum
https://www.freecodecamp.org/learn
BSD 3-Clause "New" or "Revised" License
142 stars 89 forks source link

Pokémon Proxy API: HTTPS replaced with HTTP in API response #597

Closed lasjorg closed 3 months ago

lasjorg commented 4 months ago

Describe the bug

The "get all" endpoint of the proxy is replacing the original API HTTPS links with HTTP, causing CORS blocking (mixed content). This happens if campers fetches all Pokémon and then uses the url property from the response to fetch with.

To Reproduce

https://pokeapi-proxy.freecodecamp.rocks/api/pokemon

Response (truncated to single object):

{
  "count": 1302,
  "results": [
    {
      "id": 1,
      "name": "bulbasaur",
      "url": "http://pokeapi-proxy.freecodecamp.rocks/api/pokemon/1/"
    }
  ]
}

I assume it is happening on line 28

https://github.com/freeCodeCamp/demo-projects/blob/aa9397157a6948de46951cf8a6af28cebf4a8f83/apps/pokeapi-proxy/api/pokemon/pokemon.handlers.mjs#L28C18-L28C30

Can't say I know why req.protocol would be HTTP and not HTTPS in production. Maybe it is related to Docker. Not sure if setting "trust proxy" in the express app would do anything (docs). I assume it would HTTP in dev, so I'm not sure how to test this.

@scissorsneedfoodtoo Any idea why this is happening?

Expected behavior

HTTPS API links in production.

Additional context

There are quite a few examples of this happening, but here is the latest forum post I saw.

https://forum.freecodecamp.org/t/build-a-pokemon-search-app-project-error-fetching-pokemo-data-mixed-content-error-solved/690083

scissorsneedfoodtoo commented 3 months ago

Thanks for bringing this to our attention, @lasjorg.

I'm not sure why exactly the protocol is changing there where it should be HTTPS in the vast majority of cases. It's possible it has something to do with running Express within Docker, or with our Caddy setup.

Either way, I think I tried to get a bit too fancy here, and was trying to get the resource links to work locally in development (http://localhost:/api...), and in production. The protocol could be handled much more simply.

I did a quick test, and should have a working solution for this.