Bergloper
-
Posts
20 -
Joined
-
Last visited
Posts posted by Bergloper
-
-
Anyone from Geocaching who can tell more about this?
-
I don't have a problem with more or less cache, but I do have a problem with insecure logs. So I also hope this gets picked up and looked at. 😊
-
No problem 🙂
I logged off and on, and on the AL app the situation remained the same.
I also tried to logg on, on the AL app on another device. On that device I see exactly the same as on my first device.
Conclusion: It's not aan caching issue on the first device, it's an issue on the web interface and general counter.
-
Hey Max
Thx for your reply.
As far as I know I've never deleted a visited Adventure Lab, but that doesn't mean it kan be done by accident 🙂
On the webpage I can't find any reference to deleted Adventure Labs.
This probably only shows up when you have deleted an Adventure lab I guess.
On the screenshots you see the bottom of the Adventure Lab with the missing log and on the other screenshot you see the bottom of that whole page, where you can see my first logged adventure lab (2020).
<
...
-
Few days ago we visited adventure lab https://adventurelab.page.link/j8M9
There were 5 locations, we all visited en answered correctly.
In the App we see that the 5 have been visited and that the Adventure lab is completed.
On the adventure lab website we only see 4 visited and completed locations.
Also the counter of our total found caches has 1 cache to few.
Any Idea what could went wrong and how this can be fixed?
thx
Bergloper
-
On 6/25/2022 at 1:30 AM, Max and 99 said:
I just recently noticed this too.
Good to hear I'm not the only one 🙂
-
Sometimes when I'm Geocaching I send an image via the Message Center to verify something. To add an image to a message you have the option to directly take a photo or to select an existing image. In most cases I take the photo directly via the option in the Geocaching app. My standard photo application is then opened, I take the photo and confirm the result. In certain regions there is a less good mobile connection and the forwarding of an image can take a very long time.
I synchronize images made on my mobile with a network drive. I recently noticed that directly under the DCIM folder are photos that I made via the Geocaching app. The photos have a file name with the following structure: GEO_yyyymmdd_hhmmss.png. What struck me even more is the size of the images. On average, these are 18 MB in size. Photos that I don't take via the Geocaching app are in jpg format and are on average about 5 MB in size.
I suppose I can assume that those photos that the geocaching app places directly under DCIM folder are also the photos that are attached and sent. This could explain why it sometimes takes a little longer to send a message. Is there anyone to confirm this?
If this is the case, I still have some questions.
- Why do they choose a PNG format that is so much larger (png is also more intended for drawings, not photos)?
- In most cases, the photos I send are even allowed to be a lot smaller than my regular photos. Wouldn't it be a good idea to offer via geocaching (via configuration or when the photo is confirmed) to be able to reduce photos to a certain size before they are sent? It would make sending an image a lot easier and faster. Alternatively, I either take a photo first and then add it (= more steps) or adjust the setting when I take the photo (= not user-friendly)
FYI: I can delete the images on my phone without any problem.
Thanks for your feedback!
-
13 hours ago, Goldenwattle said:
Same here, and this is serious for me, as I'm about to go travelling and I need to make pocket queries
NOW!!!!
Hi
You probably still are able to acces your pocket queries as the pages are not offline, but just not linked in the user interface.
Try https://www.geocaching.com/account/dashboard to go to your dashboard or https://www.geocaching.com/pocket/default.aspx to directly go to your pocket query configuration. 🙂
-
.png)
2
-
-
I prefer the previous user experience.
Will we be able to search a cache on, after, before of between dates?
This way it we can search all our finds and is it possible to search the cache which name or other attributes I forgot.
-
2
-
-
Ook hier kan ik het probleem bevestigen :-)
-
I also use steganography myself, both with images and with sound clips.
I always try to host my files at Geocaching.com (= Amazon Web Services). Only in the cases that I use EXIF info or non image files I am forced to host the files elsewhere (hosting at my ISP).
One of my puzzles uses images with EXIF info. Alle the images have the exact name with a suffix number (1..8). The info in the EXIF and the number in the filename are necessary to go to the next step of the puzzel. With the introduction of the proxy the filename is broken. It still is there in the URL of the proxy, but when downloading the file it is gone. The EXIF info is still available. I solved the problem with the filename by also adding this in the EXIF info. I also could visually add a number on the image.
So far this puzzle can be solved again. However, when I look in the Android Geocaching.com app, these images are not displayed, they show broken. In the Apple Geocaching.com app, the images are shown correctly. To identify the problem I also viewed a friend's cache (with an image not hosted on Geocaching.com) via the Android Geocaching.com app. The image in his listing is shown correctly. I Know there are issues visualizing images in the Android Geoaching.com app. I posted a remark in the Android App specific bug reporting forum.
thebruce0's assumption that images get broken because the proxy's processing can't validate the file structure is a plausible thinking track for some cases. I think it could occur when people are editing the image file structure (writing data in the file structure instead of e.g. the EXIF) or when you use a file with an invalid file structure. The images in my case were not structural edited, I just added the EXIF. As far as I know the image I use have a valid file structure. At least they show up correctly in the web interface.
At this moment I don't Know what I do wrong or what goes wrong. I hope that clarity will come soon.
Fortunately I only have 1 partially affected cache, but there are cache owners with more affected caches.
I understand that Geocaching.com strips EXIF info by default. Still, it would be handy if we could upload images and keep certain EXIF info or add it afterwards (by stating it explicitly). That doesn't fix all the issues caused by the introduction of the proxy but it one of the many possible steps to fix them all.
-
1
-
-
Since the last release note (January 14, 2020) Geocaching.com uses a proxy server to load/show images that are not hosted on geocaching.com (underlying hosted on Amazon Web Services). One of the reasons is that they want to block cookies from other domains. For certain puzzles that use the URL for solving the puzzle, this is a problem (see reactions in the release note topic).
I have one puzzle that uses images hosted on my personal web space because they contain EXIF info needed to solve the puzzle. I checked my puzzle and downloaded all images. The EXIF info is still available, but the filename changed. No problem to solve this puzzle.
This evening I tried to check this puzzle on the Geocaching app and noticed that the external hosted images were not shown in the app. They appear as a broken link to an image. The tother images in the listing that are hosted on Geocaching itself appear correctly. I was wondering if this is the bug mentioned in this thread or if this is a new bug introduced by using the proxyserver.
I double checked the behavior with friend's cache who is also hosting images on his own web space. His images were visible in the app.
-
1
-
-
1 hour ago, thebruce0 said:
Since you can't embed an mp3 file as an <img src>, I assume you mean you're linking to the external MP3 file as a link - that should still be possible, those links aren't being changed.
Indeed, I use de <a href=http://...> ... </a>
-
23 hours ago, Bergloper said:
I have 1 puzzle where I host images on my own website because they use EXIF info (which is removed when hosting on Geocaching itself).
I now see that the URL has been changed to "https://imgproxy.geocaching.com/09a44c6d4fac8f92622d4a4177f23e18450f0693?url=http...". When I download the image, the EXIF info is still present.
For another puzzle I use an mp3 file. I cannot host this on Geocaching. The link to this file on my website has not been changed.
Yesterday I checked the new behavior for external hosted images via the website and everything seemed to be okay.
This evening I checked the puzzle via the app and I only see broken links to the images.
That's not good.
Should I report this separately or wil this picked up here?
-
1
-
-
6 minutes ago, thebruce0 said:
Yeah it's kind of a hack, but just as javascript can write content to an open document in any window, iframe is treated as a distinct document so it can be written, thus contain HTML content that's in a sense not hosted anywhere.
That would be a better solution to the embedded image issue than rewriting all the image URLs and breaking puzzle that really don't need to be broken... =/
I agree
-
1 minute ago, thebruce0 said:
Ahh, I see the dreaded image proxy for description HTML is back.
No, HTML can be written into the iframe, so HQ simply writes the custom HTML content into that iframe, essentially contained in its sandboxed element. The same is done with your public profile HTML content, embedded within an iframe.
Thanks for the clarification.
I wrote HTML with IFrames in the past, but today it is no longer common for several reasons (security, layout, ...).
I also assumed that you always refer to another domain via an IFrame.
I know the example of how to use the profile on Geocaching and I honestly thought that the user suplied content in the listing worked in a similar way.
-
On 1/20/2020 at 9:03 AM, arisoft said:
Suggestion: If security is really an issue behind this nonsense, please embed the user editable cache description in <iframe> capsule from a separate domain. Then it has no relation to the geocaching.com framework and can not comporomise any personal data.
Which means that you have to provide the cache page on your own hosting?
I suspect that this will be a problem for many people. Not everyone is able to set up their own website and edit html. There are indeed tools for that, but I fear it could be a bridge too far.
-
I have 1 puzzle where I host images on my own website because they use EXIF info (which is removed when hosting on Geocaching itself).
I now see that the URL has been changed to "https://imgproxy.geocaching.com/09a44c6d4fac8f92622d4a4177f23e18450f0693?url=http...". When I download the image, the EXIF info is still present.
For another puzzle I use an mp3 file. I cannot host this on Geocaching. The link to this file on my website has not been changed.
<
NOW!!!!
.png)
Adventure Lab - Visited and found lab location visible in Adventure lab app, but not on the counter on Geocaching.com and not on https://labs.geocaching.com/logs
in Official Geocaching® apps
Posted
Thanks for letting us know 😊