navigate by URIs in webish.py

[zooko]

When a user is looking at a web page which represents a directory, e.g. "/dinner/", and then they click on one of the names of that directory, e.g. "spam" then there are three things that they could get:

1. The result of following the name "dinner" and then following the name "spam", i.e. the *current* value of "/dinner/spam", which could be completely different than the web page they are looking at when they click.

2. The result of following the name "spam" from the directory that they are looking at (i.e. the directory that *was* the value of the name "dinner" back when they loaded the page that they are looking at).

3. The object that *was* denoted by the name "spam" in the directory "dinner" when they loaded the page.

Brian and I discussed this on IRC, and he had the following ideas, which I confess that I only partially understood, and so I hope that I am transcribing them faithfully:

warner: we could also do GET /uri/URI?show-pathname=/blah/foo

warner: or even GET /uri/URI/show-pathname= [(blah, blahURI), (foo, fooURI)] , and have webish.py assemble the same "you are here" pathname display it does right now, with proper hrefs

warner: kind of ugly on the implementation side, but it *would* provide these secure refs to each ancestor dirnode..

zooko: Very interesting.

zooko: You mean basically ("..", parentURI) would be one of the elements of that list?

warner: not exactly, in that case .. (i.e. the "visit parent directory" link) would be handled by just copying the /uri/URI used for the last component of the pathname list

warner: at the moment, we create that "you are here" /foo/bar/blah pathname+href stuff by doing a lot of "".join(* depth?) in a loop

warner: for this approach, we'd have to pull the list out of the queryargs, unserialize them or something, then populate each component of the you-are-here string with a separate /uri/$URI entry (and include the right show-pathname= args so that it, too, could get a you-are-here list)

warner: I think show-pathname= might address the issue for webish.py

zooko: That sounds like an improvement.

zooko: short summary: "navigate by URIs in webish.py" ?

warner: although, if you *did* intend to replace a directory with something else, you could achieve just as much confusion when you're using an old web page

zooko: What do you mean?

warner: "*my* browser says /shared-with-allmydata/current-project/README", why am I not seeing the same file as you are?"

zooko: Ah, I see what you mean.

zooko: But it is still strictly more sensible that the current scheme, isn't it?

warner: "oh, my /current-project page was from last week, before we did 'tahoe mv current-project previous-project; tahoe mv new-project current-project'"

warner: not if you have the expectation that a stateless HTTP server is going to re-traverse the entire pathname on each hit :)

warner: they'd have to go back to the root and navigate downwards

warner: or maybe a button that says "jump to the current directory that is referenced by the same name"

zooko: Yeah -- strange. I guess for now it is good enough that users who encounter that situation click ".." a few times or click "home" and retraverse by hand.

zooko: That is actually what people do with local filesystems sometimes, isn't it?

warner: yeah

warner: maybe a small banner on each dirnode page with a portion of the URI

warner: you-are-here = /foo/bar/blah [a4f2]

zooko: That's interesting! :-)

warner: and maybe users would learn to compare the thing in the [] with their friend over the phone

zooko: Wouldn't hurt, if it was small and pretty enough...

zooko: :-)

[zooko]

See also the mailing list thread:

​http://allmydata.org/pipermail/tahoe-dev/2007-September/000134.html

This fits into the "security" theme for v0.6.1.

[zooko]

Bumping this to v0.7.

[zooko]

We're focussing on an imminent v0.7.0 (see ​the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

[zooko]

We need to choose a manageable subset of desired improvements for ​v0.7.1, scheduled for two week hence, so I'm bumping this one into ​v0.7.2, scheduled for mid-December.

[zooko]

Rob pointed out that as you use the wui and navigate deeper into a directory tree, it gets slower with every click. If we navigated by caps instead of sequences of names in the wui then this slow-down would not happen.

[warner]

I'm implementing a minimal part of this today. With the new patch, the "look at the child directory" links (in the left-hand column of the directory page) take the user to a URI-based URL with no child pathnames, i.e. it takes you from /uri/CAPparent to /uri/CAPchild/ instead of /uri/CAPparent/child . I've also modified the "Directory" header at the top of the page to include the URI of the directory (instead of saying "<from-uri>"). This is a bit verbose with our pre-DSA dircaps, so I won't be surprised to hear suggestions that we remove it or just show the first few characters or something.

[warner]

I think this might be done. I'll move it to the 1.2.0 milestone with the intent of reviewing the current behavior and see if it satisfies these goals.

[davidsarah]

The "navigate by URIs" part of this was fixed long ago. If I'm reading the description correctly, the design that was originally suggested would also have had ​path breadcrumbs on directory pages. But in practice the browser's Back button works fine for that, and doesn't have the potential security problem of granting unintended access to parent directories if the URL in the location bar is shared.