Freecodecamp: Weather App Location issue

[RoniqueRicketts]

Show the Local Weather

https://www.freecodecamp.com/challenges/show-the-local-weather

Weather App Location issue

I am currently using Google chrome and I have been trying to figure out why my location could not be found when I copied the exact code from FCC and placed it in Codepen.io. After a week of fighting I asked for help and I learn that I had to use https:// so I can find my location. The second issue is that when I tried to pass this location to the Weather API it would not work, so I asked the community again and I learn that the FCC given locator will not work when we pass the location to the weather API. Could you please add a side note to the other codes as a heads up so that they don't end up beating their computer with a baseball bat?

Browser Information

• Browser Name, Version: Google Chrome Version 51.0.2704.84 m
• Operating System: Windows 10
• Mobile, Desktop, or Tablet: Desktop

Your Code

// If relevant, paste all of your challenge code in here

Screenshot

[dhcodes]

I agree that the project should have a disclaimer about this. There are many questions in the chat with users providing working code that won't work in Chrome because of the update.

[robjloranger]

Which code does not work? I'm using chrome and the example app works for me.

[zeroth-hour]

Chrome 50 disallows geolocation in an insecure context (http). This means that the site has to work over https. However, the free version of openweatherapi does not allow https. This creates a problem, as mixed security contexts are also not allowed in Chrome.

[RoniqueRicketts]

We are not able to use the geolocation code and pass it to the weather api. It will not accept. The geolocation code works fine by itself but we are not able to get the location when we pass the latitude and longitude to the weather api.

[robjloranger]

So perhaps the Open Weather API should no longer be recommended?
Although I don't know of one that uses https, I just noticed my old weather project no longer works either :)

[RoniqueRicketts]

Or there could be a a note showing an alternative for finding the current location.

[dhcodes]

As a follow-up, I found a few APIs (Dark Sky and Yahoo Weather!) that have SSL in their API URL and could potentially work in chrome with HTML5.

The Dark Sky API worked temporarily with "http://crossorigin.me" prepended but stopped working soon after (probably due to cross-origin issues). It also doesn't include the city/country as part of its JSON which is a nice feature that OpenWeather has.

I didn't try Yahoo Weather! because I didn't find it to be a good option for learning APIs. It essentially provides the code for you and requires that you put their icon on it as attribution.

There may be others, but I was unable to find any that seemed like reputable (reliable, long-term) sites. Thus, I would recommend that the challenge simply acknowledges the Chrome issue and points users to use ip location instead of HTML5. I know this doesn't jibe with the earlier jQuery challenge where they use HTML5 location, but it seems to be the best route at the moment for it to work in Chrome.

[stricknein]

Dark Sky has header issue. I used http://ip-api.com/json to get the info I needed to work with the open weather map API. I will try and add a disclaimer to the challenge and put in for a pull request.

[lisaychuang]

Glad I found this issue, I thought I was going mad! I now see the issue was with Open Weather's http (insecure) for free accounts.

Just found the AccuWeather API:

Instant, Free Access to AccuWeather APIs for Developers
Register at developer.accuweather.com and get 6 months of free access to a sampling of AccuWeather API endpoints, including Locations, Current Conditions, and Daily and Hourly Forecasts.

Even though the free access is only 6months, which means the app won't work after that, it should suffice for the challenge. Can the FCC core team kindly update the instructions?

[inthegully]

This is a broken challenge that should be fixed with a disclaimer so people aren't wasting their time.

[smiller171]

I am working on creating an SSL proxy for OpenWeatherMap. Advising the use of this proxy would solve the issue. It's also incredibly easy to set up in AWS if FCC wants to host it themselves.

[dhcodes]

@smiller171 cool, I hadn't thought of that. Let us know how it goes

[smiller171]

https://weather.millergeek.xyz/ is working now. Just use that instead of http://openweathermap.org/. It does a complete passthrough of everything at the /data/ path

[smiller171]

Also I noticed someone merged a PR advising using DarkSky instead of OpenWeatherMap to Staging. Just needs to get pushed to Master and deployed

[mike2ykme]

I ended up using Yahoo's YQL and pulled the data and then crossed it with the https images from openweather. I did find that I'd have some calls that returned 0 results so I just had it wait 15seconds and then retry.

"https://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid%20in%20(SELECT%20woeid%20FROM%20geo.places%20WHERE%20text%3D%22("+lat+"%2C+"+lon+")%22)&format=json&diagnostics=true"
Just change the lat and lon you pull from your browser.

[raisedadead]

Adding a workaround:
https://github.com/freeCodeCamp/freeCodeCamp/issues/12514#issuecomment-272572768

[dhcodes]

@raisedadead did this challenge ever get updated with a new service?

The workaround doesn't solve the issue because Chrome doesn't allow HTML5 location calls over http (it requires https). Since assumedly most campers are using Chrome, they run into the issue of not being able to get the api to return results on Chrome because the openweather API and wunderground API are http and codepen won't allow mixed content to be served. Therefore, the suggested solution above of changing the challenge to use forecast.io is the preferred solution since it allows https calls and will therefore support Chrome's location requirements.

I think at one point it was suggested this challenge may end up removed, but I could be wrong on that.

All that to say, if the challenge stays, we should either:

a) recommend ip-based location instead of HTML5 location if using chrome

OR

b) recommend a weather api that supports https and clarify that campers need to connect to codepen overhttps

I'm partial to choice a because forecast.io doesn't output the city/state based on longitude and latitude like openweather does.

[PeterPartridge]

Hi @raisedadead I am doing this challenge at the moment and either of the changes you recommended would help a lot.

I spent most of the day getting my geolocation and weather api to work, jumping between HTTPS and HTTP. I finally got my codepen to work in HTTPS by using the wunderground api.

I used an ajax request with the url https://api.wunderground.com. The sites documentation says you must use HTTP but using HTTPS still return's the information.

[mike2ykme]

Use yahoo's YQL for the weather data

[marioncharlie]

I was working on Firefox so I didn't see the issue until a friend told me it wasn't working on his browser (Chrome).
I lost a lot of time trying to retrieve APIs datas cause of the HTTPS/HTTP issue too.
I finished my project so I didn't look for others API but I really think a warning on the exercice page would be great for future campers.

[greenfreq]

Why hasn't this been assigned for correction? Its a simple fix. Either remove the recommended API or alter the recommended API to one that is compliant with CodePen requirements. Having users go through the process of troubleshooting issues with the recommended API (recommended means it should work) will frustrate them. I imagine that you will continue to get Bug Reports on this until you make this simple fix.

[raisedadead]

Why hasn't this been assigned for correction? Its a simple fix

Easier said than done. Please feel free to fork the pen, and use an alternate API if you are aware, share it here, we will be happy to fork it and update official pen.

We share your frustration, but at the same time, need help in making this work under all conditions, as you may see if you go through the thread.

Nevertheless thanks for your feedback.

[YannHulot]

I had this problem the other day while redoing some of my projects in React.
I ended up finding this releases notes from google about Chrome:

Does this affect local development?

It should not, localhost has been declared as "potentially secure" in the spec and in our case geolocation requests served at the top level over localhost will still work.

For more info: https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only

Also. the funny thing was that it worked for a while using OpenWeather then stopped working suddenly.

I switched to Firefox to finish the project.

[dhcodes]

In the beta, this challenge is moved to the "take-home" projects so it's not required for a certificate. Having said that, I know this has been a long-time issue and having reread the user stories, I think we should recommend Dark Sky as it works over SSL. The reason I have hesitated to recommend it in the past is because it doesn't output the user location (city/state) as part of the API which is a nice feature of OpenWeather but it's not required by the user stories, only showing the weather is required. What do others think? I can make a PR soon if all agree.

[raisedadead]

@dhcodes Sure thing, but I would also update the current pen in that case so that while we release beta, this one is resolved and campers do not face the issue.

Let me know, if you can get it working. I'll update the official pen.

[MavisMyles]

Hey! I know that this is totally off topic, but I'm really new to this and dont know what to do next or where to go. Please Help!

[Marmiz]

@dhcodes @raisedadead Otherwise, a nice and simple "addition" would be, instead of suggesting to use get.geolocation use an IP tracker API.

They are not as precise as the Location since they will track only your public IP, but we can add a note why it's meant to be like that.
It conforms to the the challenge requirements and skills since use an API call; plus it's a nice "side" on web security and why not every data is always public and ready-to-use.

Plus some of this library are open source with an extensive documentation. I like ipfy (and I've used it in node for a cloud project. But there's also ip-api

[AlexandroPerez]

A temporary workaround

I finished my weather app a long time ago, and ran with this problem when I revisited my codepen because I'm planning on moving my code to a vps that will serve content over HTTPS. So while thinking about what other API to use, I realized I could try to accessing my codepen using HTTP instead of HTTPS, and it works. I'm not using geolocation though. I relied on another API (https) that gets the location based on the IP address.

Thankfully codepen doesn't enforce HTTPS, which for security reasons should be the standard, but for this case it works. So a temporary solution can be to let campers know they need to use codepen over HTTP instead of HTTPS when working on this challenge, and make sure they share that same link. They should probably let users know somewhere in their page that the pen should be access using HTTP as well.

All that's left for me to do is figure out how to make the API work for me in my https only portfolio site... 😓

[h1tag]

Hey there, why there's still no fix for this issue?
Everyday many campers come to the chat having this issue.
I would suggest using APIXU API. Can somebody take this?