navigate by URIs in webish.py #103

New Issue

zooko · 2007-08-14T20:12:20Z

zooko commented

2007-08-14 20:12:20 +00:00

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:

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

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 added the

labels 2007-08-14 20:12:20 +00:00

zooko added this to the undecided milestone 2007-08-14 20:12:20 +00:00

zooko added

and removed

labels 2007-08-14 20:12:43 +00:00

zooko commented

2007-09-25 04:37:26 +00:00

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.

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 added

0.6.0

and removed

0.4.0

labels 2007-09-25 04:37:26 +00:00

zooko modified the milestone from undecided to 0.6.1

2007-09-25 04:37:26 +00:00

zooko commented

2007-10-13 06:35:35 +00:00

Bumping this to v0.7.

zooko modified the milestone from 0.6.1 to 0.7.0

2007-10-13 20:15:55 +00:00

zooko commented

2007-11-01 19:36:04 +00:00

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

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

zooko added

0.6.1

and removed

0.6.0

labels 2007-11-01 19:43:19 +00:00

zooko commented

2007-11-13 18:28:44 +00:00

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.

We need to choose a manageable subset of desired improvements for [v0.7.1](http://allmydata.org/trac/tahoe/milestone/0.7.1), scheduled for two week hence, so I'm bumping this one into [v0.7.2](http://allmydata.org/trac/tahoe/milestone/0.7.2), scheduled for mid-December.

zooko added

0.7.0

and removed

0.6.1

labels 2007-11-13 18:28:44 +00:00

zooko commented

2008-01-23 00:06:38 +00:00

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.

zooko added this to the undecided milestone 2008-01-23 04:21:17 +00:00

warner commented

2008-01-29 23:50:56 +00:00

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 ""). 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.

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 commented

2008-06-01 20:52:37 +00:00

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.

warner modified the milestone from eventually to 1.2.0

2008-06-01 20:52:37 +00:00

zooko modified the milestone from 1.5.0 to eventually

2009-06-30 17:53:21 +00:00

davidsarah commented

2011-08-27 00:05:18 +00:00

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.

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](https://secure.wikimedia.org/wikipedia/en/wiki/Breadcrumb_%28navigation%29) 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.

tahoe-lafs added the

fixed

label 2011-08-27 00:05:18 +00:00

tahoe-lafs modified the milestone from eventually to 1.2.0

2011-08-27 00:05:18 +00:00

tahoe-lafs closed this issue

2011-08-27 00:05:18 +00:00

Sign in to join this conversation.