4 ms·

hash part of url only available in the browser, as far as I know, server doesn’t have access to # value

sublinear 10mo ago
Typos and URL mangles are common though, and I'd still have no way to confirm if it got logged in that case. It's out of scope for anything in the github source, and instead depends on the server hosting the page. I know this isn't meant to be super secure, but it's still worth a mention.
- throwaway150 10mo ago
  Typos aren't making the hash part turn into something else. Like your parent comment explained to you, the hash part is not sent to the server. If you go out of your way to mangle the URL then of course a mangled URL without hash will likely get logged to the server. But I'm not sure how one would manage to go so much out of the way that they mangle the URL in a way that removes the hash.
  - sublinear 10mo ago
    You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc. Percent encoding is particularly bad since it may also bloat the length causing truncation and the decompress to fail. There's endless footguns with URLs.
    - throwaway150 9mo ago
      > You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc. If an app is mangling the URL by stripping the query and hash components, then it is breaking URLs and you have a bigger problem than worrying about URLs being logged. Stop using such apps immediately and report the bugs to the app developers.
      - sublinear 9mo ago
        To my original point, if those changes to the URL cause the browser to not parse the hash component then it will be sent to the server and get logged. The idea is nice, but unreliable. The original intent was simply to link a section of a page and it should fail gracefully (and it does when used as intended).
jamesdwilson 10mo ago
very easy for the server to intentionally (or by compromise) add a one liner to send the hash text up.

Typos and URL mangles are common though, and I'd still have no way to confirm if it got logged in that case. It's out of scope for anything in the github source, and instead depends on the server hosting the page. I know this isn't meant to be super secure, but it's still worth a mention.

throwaway150 10mo ago
Typos aren't making the hash part turn into something else. Like your parent comment explained to you, the hash part is not sent to the server. If you go out of your way to mangle the URL then of course a mangled URL without hash will likely get logged to the server. But I'm not sure how one would manage to go so much out of the way that they mangle the URL in a way that removes the hash.
- sublinear 10mo ago
  You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc. Percent encoding is particularly bad since it may also bloat the length causing truncation and the decompress to fail. There's endless footguns with URLs.
  - throwaway150 9mo ago
    > You don't have a choice pasting links into some apps. They may strip out query and hash components, percent encode, force URL shortener services, etc. If an app is mangling the URL by stripping the query and hash components, then it is breaking URLs and you have a bigger problem than worrying about URLs being logged. Stop using such apps immediately and report the bugs to the app developers.
    - sublinear 9mo ago
      To my original point, if those changes to the URL cause the browser to not parse the hash component then it will be sent to the server and get logged. The idea is nice, but unreliable. The original intent was simply to link a section of a page and it should fail gracefully (and it does when used as intended).

jamesdwilson 10mo ago

very easy for the server to intentionally (or by compromise) add a one liner to send the hash text up.