Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot login to space containing comma sign #1938

Closed
4 of 5 tasks
philippthun opened this issue May 18, 2020 · 4 comments
Closed
4 of 5 tasks

Cannot login to space containing comma sign #1938

philippthun opened this issue May 18, 2020 · 4 comments

Comments

@philippthun
Copy link
Member

Please fill out the issue checklist below and provide ALL the requested information.

  • I reviewed open and closed github issues that may be related to my problem.
  • I tried updating to the latest version of the CF CLI to see if it fixed my problem.
  • I attempted to run the command with CF_TRACE=1 to help debug the issue.
  • I am reporting a bug that others will be able to reproduce.
  • If this is an issue for the v7 beta release, I've read through the official docs and the release notes.

Describe the bug and the command you saw an issue with
I have a space named a,b. When running cf login -u <user> -o <org> -s "a,b", I get Space 'a,b' not found. But executing cf target -s "a,b" succeeds.

What happened
See above.

Expected behavior
I expect that both commands (cf login -s and cf target -s) behave the same.

To Reproduce
See above.

Provide more context

  • cf version 6.49.0+d0dfa93bb.2020-01-07
  • V2 API 2.146.0
  • V3 API 3.81.0

Adding -v to the CF CLI commands shows that for cf login a call to the V3 API is sent, whereas for cf target the V2 API is used.

GET /v3/spaces?names=a%2Cb&organization_guids=b12a0c77-32ce-4ed3-ba16-aa0a1fc03e3e HTTP/1.1
=> "resources": null

GET /v2/spaces?order-by=name&q=name%3Aa%2Cb&q=organization_guid%3Ab12a0c77-32ce-4ed3-ba16-aa0a1fc03e3e HTTP/1.1
=>   "resources": [{"entity": { ...

The V3 API Docs state that the names parameter contains a Comma-delimited list of space names to filter by. - so it seems that the comma sign is causing trouble here...

I'm not sure if this is a client (CF CLI) or server (CF API) issue; maybe space names need some special encoding before they are sent to the server. As this issue shows up when using the CF CLI, I decided to open a bug here.

@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/172891571

The labels on this github issue will be updated when the story is started.

@voelzmo
Copy link

voelzmo commented Jun 17, 2020

bump
Hey, it's been a month, can we get a temperature check on this? Is this something you could have a look at? Unfortunately we have customers using commas in their spaces, which used to work fine with v2, but doesn't using the v3 API.

/cc @Gerg @ssisil

@Gerg
Copy link
Member

Gerg commented Jun 17, 2020

I'm guessing the CLI is not properly double-encoding the comma in the space name. I'll see if some engineers can look into it.

belinda-liu added a commit that referenced this issue Jun 19, 2020
The v3 API requires that the comma character is double encoded when used
in a single query parameter. Previously, the CLI would only encode the
query request once it was fully formed. This was sufficient for v2, but
with the v3 API this would cause issues when using a resource that had
commas in its name.

This commit now encodes query parameters with the
`names` filter before encoding the entire query. This ensures that
resource names that may contain commas are properly double encoded.

[Github issue #1938](#1938)
[#172891571](https://www.pivotaltracker.com/story/show/172891571)

Authored-by: Belinda Liu <bliu@pivotal.io>
reidmit pushed a commit that referenced this issue Jun 29, 2020
The v3 API requires that the comma character is double encoded when used
in a single query parameter. Previously, the CLI would only encode the
query request once it was fully formed. This was sufficient for v2, but
with the v3 API this would cause issues when using a resource that had
commas in its name.

This commit now encodes query parameters with the
`names` filter before encoding the entire query. This ensures that
resource names that may contain commas are properly double encoded.

[Github issue #1938](#1938)
[#172891571](https://www.pivotaltracker.com/story/show/172891571)

Authored-by: Belinda Liu <bliu@pivotal.io>
@Gerg
Copy link
Member

Gerg commented Jul 1, 2020

This issue should be fixed in the next release of v7.

@Gerg Gerg closed this as completed Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants