Weather Challenge - API Key Issue (Yep, let's rehash this again)

Weather Challenge - API Key Issue (Yep, let's rehash this again)
0
#1

Hello! Long time FCC Chat/Subreddit/Forum lurker, first time poster, (aside from some replies in the subreddit and some responses in chat).

I wanted to discuss the topic of the weather challenge. The issue is that we, of course, do not want to display API keys in CodePen since that is a huge security breach, (aka: Security wha…?)

I did a lot of searching about how we should be approaching this challenge when I found this Github issue started by Quincy. https://github.com/FreeCodeCamp/FreeCodeCamp/issues/3714

Unfortunately that ended up getting closed with no resolution. I decided that I would do some searches on code pen purely to see how others handled the API key issue, (I already have a good idea of how I’m going to code everything so I felt like I wasn’t cheating since all I was doing was searching their code for how they hid their API key or if they had found an API that didn’t require a key). To my amazement, every single pen I viewed had their API key displayed in the code!

I really like Forecast.io so far but I am trying really hard to find a way to hide the API key. One thought I have is that I have a webhost currently so maybe I could stick it in a PHP file, then call that file from my Codepen and the key would be hidden. Unfortunately it’s been a minute since I’ve done any serious PHP coding, so I’m not well-versed in security and I was concerned about how I could do this while ensuring no one could just go to the PHP file and download it or view it somehow. Unfortunately this may resolve it for me if there is such a solution, but I’d really like to see if we could figure out a way to make it secure for anyone who does the challenge. I feel teaching the right security methods from the get-go would prepare future developers much better.

So I bring this back up to attention, especially for those beginners who blindly put the key in their code without worrying of repercussions. What are some of the ways you more senior developers are doing to do this? Should this project be moved from Codepen altogether, and if so what would you recommend doing?

Or should we just go ahead and put the key in there anyway? I know with Forecast.io it will start charging after 1000 calls in a day, so as long as we don’t put any billing in there, our app will just stop working, (I imagine), after the 1000th call for the day.

Thanks for any responses!
–Sam

#2

Personal opinion: I don’t know if this is a huge deal or not…

The task at hand is just for learning and is not a production scale application. That being said if we really wanted a keyless source of data, what about parsing a government XML feed like: https://weather.gc.ca/rss/city/bc-84_e.xml

#3

I agree that it is purely for learning but I think the intent is to use an API to accomplish it for the purpose of learning how to interact with APIs.

Again, part of the learning, in my opinion, is to do things correctly. Starting a new developer off by putting a large security hole in their code seems like a bad idea. I was just wanting to see what others thought about rectifying this issue.

I do like the idea of maybe looking into XML data. Possibly it could be turned into a project where the learner has to locate the right xml file to pull data from based on location information, but I’m not sure if that would be too difficult.

#4

All good points! It is truly a tough nut to crack!

#5

You can try to store your api key in a db like firebase and retrieve it only when you make a request to the weather api. Although not obviously visible in the code, the key is still exposed when you view xhr requests in the dev console.

#6

I was thinking a database too but then i would have to authenticate to it meaning that part of the code would also need to be hidden, thus going back to the original problem. I haven’t used firebase so i dont know how authentication works with it but i had been thinking of it with MySQL.

#7

@sreeves89 when I tried this idea out on a project, I used the anonymous auth feature.

#8

Ah! Never thought of that. I will definitely look into that. Thanks!

#9

For what it’s worth, I’ve heard experienced developers say that for a free API, where keys are easily obtainable (for free), it’s kind of accepted/tolerated for a static site to have the key stored on the frontend since there’s no decent way around it without:

  • having a user provide their own key (very clumsy workaround in this case), or
  • building a backend that services the request, or
  • using some sort of “backend as a service” with key storage and external request functionality (FCC could theoretically set up something like this, though an API might not like so many requests with different keys coming from the same IP).

So my point is that it seems to exist in some sort of grey area because nobody wants to mess around with a backend for what should be a pretty basic static site. For a free account/key, about the worst that can happen is that your account/key gets disabled, and that’s unlikely. Free keys/accounts usually have a daily/weekly/monthly request limit anyway, so a single key isn’t very effective for spamming and if you do reach that limit, you’re only disabled temporarily.

#10

I looked into this briefly and found two answers:

Use a proxy service which presumably allows (I haven’t checked so I could be wrong) for specifying origin the origin URL, this exposes one key but you can store multiple keys on the proxy. Yahoo have a free service for this and I think that mashape acts like this also but could easily be wrong about this also. Mashape is useful anyway for these projects regardless.

Or do it on the back end which isn’t really an option. It’s sort of frustrating to use code pen because they could have some way of hiding the key but don’t.

But as noinkling already said does it really matter? Worst case scenario someone else uses your key, it’s free anyway. Showing it isn’t ideal but exposing it isn’t going to do much but maybe get it invalidated. Correct me if I’m wrong on that though.