Should API key: 20c70eae-e62f-4d3b-b3a4-8586e90f3ac8 give access to any station's public data?

I was doing some testing with the above API key, and I was able to get observation data (not just meta data) from station 28974, which is sharing data publicly.

As I understood the policy, only owners of the stations should have access to that data.

Is this api_key some master key? This looks like a bug to me.

From the API page:

Getting Started

During development and for any use that is strictly personal (one user, yourself), use this development API key:

  • 20c70eae-e62f-4d3b-b3a4-8586e90f3ac8
  • Note, this key has some limitations in terms of frequency of requests and volume of data
  • Please be aware that rights to data access my be revoked at any time for any reason. This may include, but not limited to, the number of stations accessible per key, frequency of requests, and volume of data.

the owner made it public data! what is the problem being able to access it??

Look at the policy on this page:

I’m not sure this is a bug, but you’re right that it seems inconsistent with the Data Access Policy. The development key behaves at an Enterprise level rather than a Normal level. I assume this is so applications can be easily tested at an Enterprise level. There is a usage limit though. I have seen the development API key fail because of too many concurrent requests/connections

according to the policies on this page, “any user” should not have access to observation data of both public and private stations.

With the development key, you cannot access data of any private station.
However, as stated in the API documentation… the development key allows access to observation data of public stations, but WILL be shut down in the near future.

yep… inconsistent… so needs to be clarified.

True… I’ve set a station to “private” and then tried to access it with the key and was unable to.

There is two things going on here.

First, a station marked as private cannot be accessed by anyone except the station owner. That’s clear.

Second, all public stations can be accessed via the API. At a Normal level any individual owner can access their data from their station. This access is free and is controlled by the Private Access Token/OAuth. If you want to access data from stations you don’t own, however, you have to enter into an Enterprise agreement with WeatherFlow. This costs $$$.

At the moment the development API key remains an Enterprise level key. However, this will very likely change in the future as indicated by:

  • Please be aware that rights to data access my be revoked at any time for any reason. This may include, but not limited to, the number of stations accessible per key, frequency of requests, and volume of data.

Not a “bug” per se… but rather a “cart before the horse” situation. WF implemented the dev key before setting the data access policy, in an effort to jumpstart user development.
I have chatted with @dsj about this and the Dev Key access will be modified in the near future as WF starts fully implementing the OAuth functionality. Which is the main reason for the btstWx reconfigure… :frowning:

3 Likes

Thanks for the question, @johnny.a.fernandes. We are long overdue for an update to our docs, but I promise we’re making progress!

The info provided by @peter and @btst.online is correct. The development API key has been around since the first version of our API and was included to give users a simple way to get started, but it was never intended to be used in a production environment. It has volume restrictions and will be deprecated soon. The next update to the API documentation will be consistent with the data access policy, and will focus on the access token concept, which will be the normal way developers will interface with the API (with an API key only required for “enterprise” users).

And don’t worry: we will give folks plenty of time to update code before the dev key stops working!

6 Likes

Thanks! I’ve been talking to Keith Koenig at WF… he’ll be able to tell you why I’m asking about this.
Anyway, I’ve gone ahead and created a token for myself to access my station(s)… seems to be working as expected.

1 Like

The ‘share publicly’ setting in the app indicates that the station owner has given permission for WeatherFlow to share data that their station uploads publicly through WeatherFlow/Tempest apps. But access to data by third-parties via the API is still bound by the data access policy.

8 Likes

I have a suggestion. Since people will have to create their own tokens, when you send people to “https://tempestwx.com/settings/tokens” and they are not logged in, the log in page should redirect them back to it once they log in successfully.

3 Likes

I’m working on a product that is going to be dependent on the API Key generation process. I have a help me page with a link to the user’s token generation site and as @93ben points out the link is lost if the user has to login. I second ben’s request to keep the link when having to login.

Here are a few more suggestions / questions:

  • Would it be possible to add a copy button to a key that has already been created as you do for a new key?
  • It seems to take a very long time for a new token to become valid in the system. Will this be improved? Is there a way my app can test for a valid token while the system is adopting it? I would like to give the user feedback right away when they type in a new token.
  • Is there a way I can generate the token programmatically if I prompt for the user’s login ID and Password that will work around these issues? (I prefer to not do it this way but will if it is the only choice).

Thanks for all the great work on your API!! I can make what you have work just though I would chime in.

1 Like

It’s really simple with the REST API, it returns this JSON array…

{"status":{"status_code":401,"status_message":"UNAUTHORIZED"}}

All you would need is that 401 code and that would tell you if the token is invalid.

1 Like

@jhrucker to add on that if the user has a valid token but the station doesn’t exist under that user it produces a 404 error.

Maybe I wasn’t clear. I know how to determine if the token is not valid that is not the problem. The problem is when a user generates a new valid token and types it in or cuts and pastes it into my app I have no way of letting the user know they have correctly typed it in. The token is not valid for several minutes. If I make a call with the “new token” it comes back with an error. However, if I wait a few minutes and make the call it is valid.

That’s odd because when I type the token in, it’s already valid just after I create it.

You could do a preg_match with the token…

/^[A-Za-z0-9]{8}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{12}$/

1 Like