Repository navigation
Name the address the login opened, instead of adding a second one - #262
Merged
Merged
Conversation
Typing an address, logging in, and pressing Use this login left the address list holding two entries. The typed address stayed, and the address the login ended on was appended with the bundle name on it. So the copy gained a second root that nobody asked for. The engine is now given the address the window was opened for, not the one the login ended on. The name goes on that same line. The list keeps one entry, and the user's own spacing and other addresses come back byte for byte. Two things follow from naming the crawl's own address. The bundle's scope is the site being copied, so a login through an identity provider drops that provider's cookies, which the crawl never needed. And that provider can no longer become a crawl root, so the warning about landing elsewhere has nothing left to warn about and goes. The landed address is no longer offered. On Android the field is never empty, because the login button needs an address. That address was therefore always an addition rather than the only root. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
A review round found the fix still appended a second address whenever the typed one carried a fragment. The engine cuts a fragment, trims a trailing host dot, and puts an international host into ASCII. So the address it hands back need not equal the token the field holds, and the match fell through to the fallback line. The token is matched by identity instead. One function picks the address the login opens, and both the window and the naming call it, so the two cannot pick differently. Two more things the same round found: - The engine refuses an address holding a password, so the login hands it none. The crawl still authenticates from the field's own copy. - Two of my own tests put the name on the field's second address. The login opens the first, so the engine could never have returned the address they claimed. Both premises were wrong, not the code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
A mutation run over this branch found four behaviour changes that no test could see, so each one is now driven rather than grepped. The worst was mine. Naming the token replaced it with the engine's own address, which carries no credentials, because the engine refuses a paste that holds any. So a field reading user:pw@host lost its password, and the comment beside it claimed the opposite. The userinfo now goes back on after the naming. The others: - Deleting dropOtherBundles turned nothing red. That call is what keeps one bundle per project, and the engine refuses to start a crawl that names two for one site. - The apply path's stripping of older names turned nothing red either. Forget calls the same function on the same map entry, so an assertion naming that call is satisfied without the apply path stripping at all. The assertion now names the assignment. - Dropping the '#' arm from the authority scan turned nothing red, so an address could be rewritten to another host. The token to name is now read from the stripped text, because reading it before stripping named a token the field no longer held. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
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
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.
Typing an address, logging in, and pressing "Use this login" left two entries in the address list. One was the typed address, the other the address the login ended on, carrying the bundle name. The copy gained a root nobody asked for.
The engine now gets the address the window was opened for. The bundle name goes on that same token, so the list keeps one entry. One function picks that address, and both the window and the naming call it.
The bundle's scope becomes the site being copied. A login through an identity provider therefore drops that provider's cookies and cannot become a crawl root. That inverts what shipped: the provider's cookies were kept and the site's own session was dropped, so such a crawl could not authenticate at all.
The landed address is no longer offered. The login button already needs an address, so that address was always an addition, never the only root.