fix: validate CLI using REST / instead of REST /info

[spena]

BREAKING CHANGE: Previously CLI startup permissions were based on whether the user has access to /info, but now it's based on whether the user has access to /. This change implies that if a user has permissions to / but not /info, they now have access to the CLI whereas previously they did not.

Description

The CLI currently makes a call to GET /info to validate if a client can connect to the KSQL server. If the server is not authorized to access the endpoint, then the CLI displays the correct access error (or any other access) on the console.

With the introduction of the KSQL security extensions, these REST endpoints might have different access restrictions. For instance, the GET /info call might be opened to any authenticated user to get information about the KSQL server (such as KSQL and Kafka clusters IDs) and send the info to the KSQL admins to request access this KSQL server. Because of this, then the CLI will never show if a user is authorized to access the server during the CLI initialization.

To improve this CLI message, we should validate the client using the GET / endpoint instead. This endpoint is not used and looks like a dummy endpoint.

Testing done

• Modified the current unit tests to use the new endpoint
• Verified the CLI messages manually:

 ./bin/ksql --user u1 --password u1 http://localhost:8088                 
...

CLI v5.4.0-SNAPSHOT, Server v5.4.0-SNAPSHOT located at http://localhost:8088

Having trouble? Type 'help' (case-insensitive) for a rundown of how things work!

Couldn't connect to the KSQL server: Access denied: Contribute permissions required to access "GET /"

ksql>

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[vcrfxia]

Hey @spena I'm having trouble understanding why this is different. Doesn't / simply redirect to /info? How could the two have different permissions?

ksql/ksql-rest-app/src/main/java/io/confluent/ksql/rest/server/resources/RootDocument.java

Line 45 in 147336a

return Response.temporaryRedirect(uri).build();

[spena]

@vcrfxia That line just returns a response to the caller about the new location the caller must be redirected. It does not do the redirection automatically unless your client manages that. For instance, a Web browser will look into the HTTP response to see if there is a new location that needs to be redirected.

Here's what CURL gets:

$ curl -v http://localhost:8088
....
> GET / HTTP/1.1
> Host: localhost:8088
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 307 Temporary Redirect
< Date: Tue, 13 Aug 2019 14:37:18 GMT
< Location: http://localhost:8088/info
...

[vcrfxia]

That line just returns a response to the caller about the new location the caller must be redirected. It does not do the redirection automatically unless your client manages that.

To check that I understand correctly, you're saying that if a user has access to /info but not /, then when the user tries to start the CLI the CLI will show that the user does not have permissions to access the KSQL server, despite the redirect response? If so, the changes here LGTM.

Can you call out the fact that this is a breaking change by adding BREAKING CHANGE: (followed by an explanation) into the PR description, and also ensure that the BREAKING CHANGE: line is propagated through to the commit body when the PR is merged? That way this change will be called out in our auto-generated changelogs. Here's the relevant section of our CONTRIBUTING.md: https://github.com/confluentinc/ksql/blob/master/CONTRIBUTING.md#breaking-changes

[spena]

That's correct @vcrfxia

Regarding the breaking change, I'm not sure I'm breaking something here. The CLI will continue working as before. No new output is added or modified. If something is broken, that would be on the REST endpoint authorization which is handled by an external authorization library which is not exposed in this code.

Or what do you think would break?

[vcrfxia]

"Breaking change" doesn't mean anything is broken, but rather that the PR introduces backwards-incompatible behavior. The behavior that's changed here is that previously CLI startup permissions were based on whether the user has access to /info, but now it's based on whether the user has access to /. This change implies that if a user has permissions to / but not /info, they now have access to the CLI whereas previously they did not. While I don't expect this to be a common case, I think it's worth calling out in our changelogs (and also generally good to get in the habit of calling out breaking changes, even if minor).

[spena]

thanks @vcrfxia . I used your same comment in the breaking change in this PR. You used the right words to describe it :).

What do you think?

[vcrfxia]

Thanks @spena -- LGTM! Friendly reminder to propagate the "BREAKING CHANGE: [...]" text from the PR description into the commit message body when you merge the PR :)

[spena]

I'll force the merge. Jenkins is failing on the Twislockscan phase, which seems flaky.