arminus
-
Posts
43 -
Joined
-
Last visited
Posts posted by arminus
-
-
10 hours ago, thebruce0 said:
I might suggest, as a web developer, to add a filename to the url. In this case, browsers can indeed still display an image given that url, but they have to make assumptions, since technically the img tag is intended to identify an image file. In good syntax, the url would be better written something like src="https://www.xctrails.org:9443/image.png" (given you say it write PNG data) with the content-type response header as image/png. Presumably, the proxy is being very strict about proper syntax, and likely think the url is untrustworthy since the file type isn't provided by URL - and since a 'hack' may theoretically employ telling the browser a different file type than the data which is actually sent, it's kind of like a spam-score. If the file extension doesn't match the data type, then it could be considered potentially malicious.
So while I'm not saying it's all on you, it is something to keep in mind - if you're sending a PNG image, then provide a URL with the PNG extension so browsers can have a better sense that they should expect a PNG file, ensure the content-type of the http response matches the file type, and the data received is PNG data matching all of the above.
It's possible that if any of those items don't match, the proxy will not serve a valid copy of the image.
An argument could be made either way - the proxy is way to strict, or the proxy is maintaining good security against potential malicious content which browsers otherwise let slip through. (But IMO the proxy is being WAY to strict =P)
Actually, I was beginning to think along the same lines after I've posted this yesterday. And lo and behold, adding an "image/png" content type header, "Content-Disposition", "inline; filename=\"image.png\"" for good measure, and accepting a URL like you suggested to my servlet-mapping's url-pattern solves the issue.
While the omission of the content type header was actually lazy on my part (it did work though for years), I think the need to have a request URL which matches .png/.jpg/... is in fact way too strict. Apparently, setting the Content-Disposition header only isn't enough.
And there's another change (probably unrelated to the proxy): Saving an img URL like the following
<img src="https://www.xctrails.org:9443/image.png?gcid=GC6B56W&stats=true" />
replaces it with
<img src="https://www.xctrails.org:9443/image.png?gcid=GC6B56W&stats=true" />
This didn't happen the last time I saved that cache page and basically implies that you can't use more than one parameter for an image request anymore either. I can hack around that, but just FYI for anyone reading this.
-
.png)
1
-
-
Same problem here:
I have 2 caches where I embed images which are generated dynamically on my server:
https://www.geocaching.com/geocache/GC5DC9R_ja-wo-isse-denn
The code on the description page says
<img src="https://www.xctrails.org:9443" />
this gets rewritten now as
<img src="https://imgproxy.geocaching.com/ab78f50389ad69e6dd6dc249b5e493abd07368f9?url=https%3A%2F%2Fwww.xctrails.org%3A9443">
and doesn't work anymore. My endpoint on xctrails.org only generates a PNG, no cookies etc. This worked flawlessly for years and is now obviously broken with the imgproxy rewrite.
Same on https://www.geocaching.com/geocache/GC6B56W_in-7-tagen-um-die-welt
Do you intend to fix this and when (I'll eventually get asked by the reviewers when I can activate those caches again) or will this remain as is?
-
1
-
1
-
-
9 minutes ago, HiddenGnome said:
Hi @arminus - geocaches that were created earlier this week and published today are not currently receiving a Clue which includes the geocache that you mentioned. We are currently working to update the system to make sure that Clues are correctly distributed going forward. Geocaches that were recently published have had a Clue added retroactively. Now that the geocache includes a clue you will need to re-log the geocache in order to receive your Clue.
great, re-logging yields the souvenir, but clicking on it (https://www.geocaching.com/souvenir/?guid=e234c8a2-191d-4727-81aa-41fd61405daf)
gives my a 500...
-
4 minutes ago, igator210 said:
Was it published before the official start time of the promotion? Not just the day of?
I read somewhere that the start time would be July 11 UTC, so the publish at 14:00 CEST today should fall into that range (even if they accidentally used -9 hours Pacific Time)
-
2 hours ago, HiddenGnome said:
The issue should now be resolved. The fastest way to get your clue will be to (once again) delete your log and re-post it. I will follow-up with a further explanation shortly.
can't confirm this: https://www.geocaching.com/geocache/GC88KZ2
Published today, should have an inspector clue according to the blog entry ("New geocaches published between July 11 and August 11, 2019 will all receive the detective clue.")
just deleted the log and re-logged it (Firefox on the website) - still no clue
deleted again, tried to log through the app, can't log a found since the app thinks I already found it
re-logged it on the website (and generated some spam for the watchers I guess...) - again no clue
-
10 days now apparently and still no fix?
-
Hi,
schau Dir mal XCTrails an, bzw. den Blog dazu, vielleicht findest Du da etwas das Du brauchen kannst, bzw. vielleicht meinst Du diese Funktion?
-
Es gibt auch noch eine "one-stop" Alternative: Rad- oder Wander-Route planen und Caches einsammeln auf einer Online Karte. XCTrails routet über Openstreetmap-Daten (d.h. auch über Feld und Waldwege) und kann anschließend Caches einsammeln und wieder in ein PQ übertragen. Hier gibt's einen Video-Podcast der zeigt wie das geht.
Grüße,
Armin
-
I think you might need to enable GPX Version 1.0.1 to get the Fav points in the GPX files.
This is set to 1.0.1 since a long time. Do you get FPs in GPXs ?
(observing the iPhone App, it seems that it downloads additional data like FPs via the API)
-
And still nothing
Which is curious since the RelNotes for the iOS 5.1 version state that favorite points are available in pocket queries ? But I just checked a current GPX - nothing ...
-
There is an update to the GPX format that has been in the works for some time now. It will include a new cache size (nano), Favorites points, edited coordinates, and other enhancements. It was supposed to be out earlier this year, but has obviously been delayed.
edited ccordinates, wouldn't that be nice ... I recently only realized out in the boonies that a PQ I had downloaded with an edited set of coordinates for a mystery still showed the original coordinates in the iPhone app
-
Favorite points and the other data is available via API. The iPhone uses the API.
I know, but the API requires a network connection and also is subject to download limits. Having the FPs present in the PQ GPX would provide them for offline usage, etc. And it seems GS has planned that some time ago anyway, so I was just wondering ...
-
Is there any update on this ? It seems that FPs are still not present in the GPXs, but curiously enough, after having downloaded a PQ in the iPhone app, the app shows the FPs ?
-
Hi all,
there was a thread on this topic about a year ago. I wonder what the status is ? I've uploaded a GPX file as generated by a PQ (so the GPX is fully compliant to the geocaching.com format), I see it in http://www.geocaching.com/pocket/saved.aspx - but it doesn't show up in the iPhone app's PQ download page. Is this supposed to work now or has the feature been skipped in the meantime ?
Thanks,
Armin
.png)
Release Notes (Website: Reverse Image proxy) - January 24, 2020
in Geocaching HQ communications
Posted
For me it is. As soon as I omit the image.png part in the img src url, I get the 404 again, just double-checked that to be sure.
I have an Apache proxy in front of my Tomcat, maybe that's the reason (I remember some settings for Apache to pass headers or not, etc.) At any rate, I have a working solution, just reporting what works for me and what doesn't ;-)