<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Webcams V3 token for images]]></title><description><![CDATA[<p dir="auto">Hi Windy,</p>
<p dir="auto">With the new V3 API, we now need to retrieve a token to access the url of the webcam images. I understand the purpose of securing the urls, but why not simply use our API key to retrieve those urls instead of this token?</p>
<p dir="auto">We now have to save a token somewhere, which means more ressources usage (write on disk every x hours), which is not very ESG compliant. The API key would be enough to secure those urls, in my opinion. Any reason on why to use a token instead ? There are many other way to secure access to data without the struggle to collect a token every time.</p>
<p dir="auto">Thank you for any clarification on this technical choice.</p>
]]></description><link>https://community.windy.com/topic/28860/webcams-v3-token-for-images</link><generator>RSS for Node</generator><lastBuildDate>Sat, 07 Mar 2026 19:14:10 GMT</lastBuildDate><atom:link href="https://community.windy.com/topic/28860.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 03 Oct 2023 16:13:18 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Webcams V3 token for images on Thu, 05 Oct 2023 13:37:21 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/kekert" aria-label="Profile: kekert">@<bdi>kekert</bdi></a> said in <a href="/post/163202">Webcams V3 token for images</a>:</p>
<blockquote>
<p dir="auto">You don't have to save the token, it is already in the url. All you have to do is to call the API before each page load (in order to have urls of the images with fresh tokens)</p>
</blockquote>
<p dir="auto">OK cool. I thought the token was also designed to minimize API usage.</p>
]]></description><link>https://community.windy.com/post/163230</link><guid isPermaLink="true">https://community.windy.com/post/163230</guid><dc:creator><![CDATA[senaika]]></dc:creator><pubDate>Thu, 05 Oct 2023 13:37:21 GMT</pubDate></item><item><title><![CDATA[Reply to Webcams V3 token for images on Thu, 05 Oct 2023 09:36:20 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/senaika" aria-label="Profile: senaika">@<bdi>senaika</bdi></a> if your API requests wouldn't be exposed (you would call them server side), that could work. But this is not the case, those requests for webcams API are usually called directly from the client. Also, url for actual webcam image is stable, without expiring tokens, you would get access to latest images forever.</p>
<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/senaika" aria-label="Profile: senaika">@<bdi>senaika</bdi></a> said in <a href="/post/163098">Webcams V3 token for images</a>:</p>
<blockquote>
<p dir="auto">My main pain point with your current solution is that we have to save a token for every single image url, and then calculate when we have to collect it again.</p>
</blockquote>
<p dir="auto">You don't have to save the token, it is already in the url. All you have to do is to call the API before each page load (in order to have urls of the images with fresh tokens)</p>
]]></description><link>https://community.windy.com/post/163202</link><guid isPermaLink="true">https://community.windy.com/post/163202</guid><dc:creator><![CDATA[kekert]]></dc:creator><pubDate>Thu, 05 Oct 2023 09:36:20 GMT</pubDate></item><item><title><![CDATA[Reply to Webcams V3 token for images on Wed, 04 Oct 2023 14:57:58 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/kekert" aria-label="Profile: kekert">@<bdi>kekert</bdi></a> Thank you for your reply.</p>
<p dir="auto">I'm far from being a security expert ;) but most API I used always relied on an API key or a signed certificated to protect their data.</p>
<p dir="auto">If we assume the key could be stolen by reading the network communication, I don't see how the token would increase security. A hacker could always still the key, and make the urls requests to collect the token. Also, your other API (forecast, map) doesn't seem to have a token to protect the data, which is why I'm surprised with this token implementation for the image urls.</p>
<p dir="auto">My main pain point with your current solution is that we have to save a token for every single image url, and then calculate when we have to collect it again.</p>
]]></description><link>https://community.windy.com/post/163098</link><guid isPermaLink="true">https://community.windy.com/post/163098</guid><dc:creator><![CDATA[senaika]]></dc:creator><pubDate>Wed, 04 Oct 2023 14:57:58 GMT</pubDate></item><item><title><![CDATA[Reply to Webcams V3 token for images on Wed, 04 Oct 2023 11:46:18 GMT]]></title><description><![CDATA[<p dir="auto">Hello <a class="plugin-mentions-user plugin-mentions-a" href="/user/senaika" aria-label="Profile: senaika">@<bdi>senaika</bdi></a>, the reason for that is simple. If the images were protected by an API key, it could be easily stolen, and since it usually has unlimited validity, it could then be misused by whoever reads the network communication. The token, on the other hand, has limited validity and is bound to a particular URL.</p>
<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/senaika" aria-label="Profile: senaika">@<bdi>senaika</bdi></a> said in <a href="/post/162939">Webcams V3 token for images</a>:</p>
<blockquote>
<p dir="auto">There are many other way to secure access to data without the struggle to collect a token every time.</p>
</blockquote>
<p dir="auto">If you know about a better way how to secure the publicly available urls, please, let us know.</p>
]]></description><link>https://community.windy.com/post/163071</link><guid isPermaLink="true">https://community.windy.com/post/163071</guid><dc:creator><![CDATA[kekert]]></dc:creator><pubDate>Wed, 04 Oct 2023 11:46:18 GMT</pubDate></item></channel></rss>