This should fix finally the issue @frozenpandaman is dealing with in #16.
We'll (finally) check the portal's port list against all of our hashes. A "hash" can be 1327ca6d4caf3c4665f5b82d72a5dc716ddf24f58f253e857c5703b9b6a69838 (resolved) or elifessler.com (the current domain name).
Latter should get resolved to the actual hash when the portal gets registered, anyway, but it will still cause issues when someone on an older version has got elifessler.com in their ports and eli is checking their portal from 1327...9898.
We could try resolving the URLs in followed portals' ports, but
it'd strain the user's data connection even more
it'd cause unnecessary refreshes once we resolved it
it will be unnecessary once enough people move on to 1.8+ and after some time passes.
(Alternatively, check if the dat field in our own portal.json contains a "masked" URL to check against, but we're moving away from the dat field as it's just causing a handful of other issues...)
This PR also fixes the dat command not working properly and makes the dat and undat commands refresh the portals list and feed.
This should fix finally the issue @frozenpandaman is dealing with in #16.
We'll (finally) check the portal's port list against all of our hashes. A "hash" can be
1327ca6d4caf3c4665f5b82d72a5dc716ddf24f58f253e857c5703b9b6a69838
(resolved) orelifessler.com
(the current domain name).Latter should get resolved to the actual hash when the portal gets registered, anyway, but it will still cause issues when someone on an older version has got
elifessler.com
in theirports
and eli is checking their portal from1327...9898
.We could try resolving the URLs in followed portals'
port
s, but(Alternatively, check if the
dat
field in our ownportal.json
contains a "masked" URL to check against, but we're moving away from thedat
field as it's just causing a handful of other issues...)This PR also fixes the dat command not working properly and makes the dat and undat commands refresh the portals list and feed.