automatically url-decode capabilities in cli #1806

New Issue

tahoe-lafs · 2012-09-14T12:25:55Z

ChosenOne commented

2012-09-14 12:25:55 +00:00

currently copy&paste from WUI to CLI messes things up, when capstrings come into play:
my browser shows colons as %3A and I don't like replacing them every time.

How about the CLI automatically URL-decoding capstrings when required?
I suppose that this might pose a few risk, so afaict a simple string capstr.replace("%3A",':') might suffice? Are there other special chars we'd need to take care of?

currently copy&paste from WUI to CLI messes things up, when capstrings come into play: my browser shows colons as %3A and I don't like replacing them every time. How about the CLI automatically URL-decoding capstrings when required? I suppose that this might pose a few risk, so afaict a simple string `capstr.replace("%3A",':')` might suffice? Are there other special chars we'd need to take care of?

tahoe-lafs added the

labels 2012-09-14 12:25:55 +00:00

tahoe-lafs added this to the undecided milestone 2012-09-14 12:25:55 +00:00

zooko commented

2012-09-14 17:21:16 +00:00

Hm, [uri.py]source:src/allmydata/uri.py@20120509200714-66853-a322b18cb1762fd5b1d1733acd8ff2aa0daf6494 already has a regex that accepts either : or %3A in those spots. Maybe we just need to make sure that the CLI passes the strings to uri.py instead of trying to parse the strings itself? What is the error that occurs when you paste a cap with "%3A" in it to the CLI?

Hm, [uri.py]source:src/allmydata/uri.py@20120509200714-66853-a322b18cb1762fd5b1d1733acd8ff2aa0daf6494 already has a regex that accepts either `:` or `%3A` in those spots. Maybe we just need to make sure that the CLI passes the strings to `uri.py` instead of trying to parse the strings itself? What is the error that occurs when you paste a cap with "%3A" in it to the CLI?

tahoe-lafs added

1.9.0

and removed

1.9.2

labels 2012-09-14 17:26:49 +00:00

ChosenOne commented

2012-09-14 17:28:18 +00:00

Sorry, this is 1.9.0. Maybe it's already included in 1.9.2?

Here's the output

$ tahoe add-alias delme URI%3ADIR2%3Amchangethisay4wy7i%3Aocblablablawrongcapstringblablaq
Traceback (most recent call last):
  File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/runner.py", line 117, in run
    rc = runner(sys.argv[1:], install_node_control=install_node_control)
  File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/runner.py", line 102, in runner
    rc = cli.dispatch[command](so)
  File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/cli.py", line 507, in add_alias
    rc = tahoe_add_alias.add_alias(options)
  File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/tahoe_add_alias.py", line 48, in add_alias
    cap = uri.from_string_dirnode(cap).to_string()
  File "/home/freddy/opt/tahoe-lafs/src/allmydata/uri.py", line 949, in from_string_dirnode
    assert IDirnodeURI.providedBy(u)
AssertionError

Sorry, this is 1.9.0. Maybe it's already included in 1.9.2? Here's the output ``` $ tahoe add-alias delme URI%3ADIR2%3Amchangethisay4wy7i%3Aocblablablawrongcapstringblablaq Traceback (most recent call last): File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/runner.py", line 117, in run rc = runner(sys.argv[1:], install_node_control=install_node_control) File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/runner.py", line 102, in runner rc = cli.dispatch[command](so) File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/cli.py", line 507, in add_alias rc = tahoe_add_alias.add_alias(options) File "/home/freddy/opt/tahoe-lafs/src/allmydata/scripts/tahoe_add_alias.py", line 48, in add_alias cap = uri.from_string_dirnode(cap).to_string() File "/home/freddy/opt/tahoe-lafs/src/allmydata/uri.py", line 949, in from_string_dirnode assert IDirnodeURI.providedBy(u) AssertionError ```

davidsarah commented

2012-09-14 20:43:19 +00:00

Duplicate of #942. I'll add a note to that ticket to say it applies to both the CLI and WUI (the latter doesn't accept URL-escaping in form fields).

tahoe-lafs added the

duplicate

label 2012-09-14 20:43:19 +00:00

davidsarah closed this issue

2012-09-14 20:43:19 +00:00

davidsarah commented

2012-09-14 20:54:13 +00:00

Replying to zooko:

Hm, [uri.py]source:src/allmydata/uri.py@20120509200714-66853-a322b18cb1762fd5b1d1733acd8ff2aa0daf6494 already has a regex that accepts either : or %3A in those spots. Maybe we just need to make sure that the CLI passes the strings to uri.py instead of trying to parse the strings itself? What is the error that occurs when you paste a cap with "%3A" in it to the CLI?

SEP, which contains the "%3A", is only used in the HUMAN_RE regex for each URI class, not for the STRING_RE regex. As far as I know the HUMAN_RE regexes are never used (I thought there was a cleanup ticket about that, but I can't find it if there is).

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1806#issuecomment-89507): > Hm, [uri.py]source:src/allmydata/uri.py@20120509200714-66853-a322b18cb1762fd5b1d1733acd8ff2aa0daf6494 already has a regex that accepts either `:` or `%3A` in those spots. Maybe we just need to make sure that the CLI passes the strings to `uri.py` instead of trying to parse the strings itself? What is the error that occurs when you paste a cap with "%3A" in it to the CLI? `SEP`, which contains the `"%3A"`, is only used in the `HUMAN_RE` regex for each URI class, not for the `STRING_RE` regex. As far as I know the `HUMAN_RE` regexes are never used (I thought there was a cleanup ticket about that, but I can't find it if there is).

davidsarah commented

2012-09-14 21:03:07 +00:00

Replying to [davidsarah]comment:5:

As far as I know the HUMAN_RE regexes are never used (I thought there was a cleanup ticket about that, but I can't find it if there is).

Filed as #1807.

Replying to [davidsarah]comment:5: > As far as I know the `HUMAN_RE` regexes are never used (I thought there was a cleanup ticket about that, but I can't find it if there is). Filed as #1807.

jg71 commented

2012-09-28 16:30:33 +00:00

+1

Sign in to join this conversation.