fix(section anchors): leave the page counter out of the copied link - #661
Merged
Merged
Conversation
Clicking the "#" handle next to a view display copied the address bar as it stood, and Wicket keeps a counter for the page instance it is serving at the front of the query string, as a parameter with no value: https://nanodash.knowledgepixels.com/space?0&id=https://w3id.org/spaces/... That counter belongs to one visit and means nothing to whoever the link is sent to, so the copied link now leaves it out and reads: https://nanodash.knowledgepixels.com/space?id=https://w3id.org/spaces/...#messages Any other valueless number in the query string goes the same way, since nanodash's own parameters all have names. Where the counter was the only thing in the query string the "?" goes with it, and an address that never had one is copied unchanged. The link the handle itself navigates to is untouched: it is the bare "#section" and never carried the counter. Closes #650 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NSAawRfUm4Au1UkejyNKY1
Member
Author
|
@tkuhn should we also strip the session ID when the cookies are disabled? See the last section above. |
Contributor
|
Yes, we should also strip the session ID |
When the visitor has cookies disabled, Wicket rewrites URLs with the session id in the path: https://nanodash.knowledgepixels.com/space;jsessionid=79B384...?0&id=... Copying that as-is hands whoever the link is sent to a live session, which is worse than the page counter the previous commit dropped. The copied link now leaves it out as well: https://nanodash.knowledgepixels.com/space?id=...#messages The strip is scoped to the path, so a query value that happens to contain ";jsessionid=" -- an "id=" pointing at some other URL, say -- is left alone. It is case-insensitive and applies to every path segment, not just the last. Closes #650 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014dByNErNfuj4au4r5vMsbf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #650.
Clicking the
#handle next to a view display copied the address bar as it stood. Wicket keeps a counter for the page instance it is serving and puts it at the front of the query string, as a parameter with no value, so what landed on the clipboard was:That counter belongs to one visit and means nothing to whoever the link is sent to.
The change
One helper in
nanodash.js,shareableUrl(), which drops valueless numeric parameters and hands back the rest — nanodash's own parameters all have names, so nothing else matches it:Where the counter was the only thing in the query string the
?goes with it, and an address that never had one is copied unchanged. The link the handle itself navigates to is untouched: it is the bare#sectionand never carried the counter.+16 −1, in one file.
Checking it
The URL shape is not guesswork: the live instance hands out
.../space?0&id=…, counter first and real parameters after, which is what the helper is written against.There is no JS test harness in this repository, so I checked the shipped function rather than a copy of it — a script that pulls
shareableUrlout ofnanodash.jsand runs it over the shapes that matter:/space?0&id=https://w3id.org/spaces/…/space?id=https://w3id.org/spaces/…/?0//space?12&id=abc#messages/space?id=abc/space?id=abc(no counter)/space(no query string)/view-results?4&view=…&context=…/view-results?view=…&context=…/space?3&limit=10/space?limit=10/space?3&flag=/space?flag=The last two are the ones worth having: a parameter whose value is a number, and one whose value is empty, both have to survive.
node --checkon the whole file passes.Noticed, not changed
When cookies are disabled, Wicket rewrites URLs with the session id in the path —
https://nanodash.knowledgepixels.com/space;jsessionid=79B384E45A46E89B10C7E281ECF70487?0&id=…, which is what the live server hands back over curl. In that state the copied link carries a live session id to whoever it is sent to, which is worse than the counter this issue is about. It does not arise for ordinary cookie-enabled visitors and it is outside what #650 asks for, so it is left alone here; happy to strip it too, in this PR or its own issue.🤖 Generated with Claude Code
https://claude.ai/code/session_01NSAawRfUm4Au1UkejyNKY1