#103 closed enhancement (fixed)

navigate by URIs in webish.py

Reported by: zooko Owned by: warner
Priority: minor Milestone: 1.2.0
Component: code-frontend-web Version: 0.7.0
Keywords: wui directories breadcrumbs usability navigation security Cc:
Launchpad Bug:


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.
  1. 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).
  1. 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: :-)

Change History (13)

comment:1 Changed at 2007-08-14T20:12:43Z by zooko

  • Component changed from unknown to code-frontend-web
  • Owner changed from nobody to warner
  • Priority changed from major to minor

comment:2 Changed at 2007-09-25T04:37:26Z by zooko

  • Milestone changed from undecided to 0.6.1
  • Version changed from 0.4.0 to 0.6.0

See also the mailing list thread:


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

comment:3 Changed at 2007-10-13T06:35:35Z by zooko

Bumping this to v0.7.

comment:4 Changed at 2007-10-13T20:15:55Z by zooko

  • Milestone changed from 0.6.1 to 0.7.0

comment:5 Changed at 2007-11-01T19:36:04Z by 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.

comment:6 Changed at 2007-11-01T19:43:19Z by zooko

  • Milestone changed from 0.7.0 to 0.7.1
  • Version changed from 0.6.0 to 0.6.1

comment:7 Changed at 2007-11-13T18:28:44Z by zooko

  • Milestone changed from 0.7.1 to 0.7.2
  • Version changed from 0.6.1 to 0.7.0

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.

comment:8 Changed at 2008-01-23T00:06:38Z by 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.

comment:9 Changed at 2008-01-23T04:21:17Z by zooko

  • Milestone changed from 0.7.2 to undecided

comment:10 Changed at 2008-01-29T23:50:56Z by 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.

comment:11 Changed at 2008-06-01T20:52:37Z by warner

  • Milestone changed from eventually to 1.2.0
  • Status changed from new to assigned

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.

comment:12 Changed at 2009-06-30T17:53:21Z by zooko

  • Milestone changed from 1.5.0 to eventually

comment:13 Changed at 2011-08-27T00:05:18Z by davidsarah

  • Keywords wui directories breadcrumbs usability navigation security added
  • Milestone changed from eventually to 1.2.0
  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.