Non-default basePath causes issues with URL path escaped subject names

[pkwarren]

Problem

Loading the schema registry UI or attempting to click 'Produce Record' on a topic integrated with the schema registry fails. The console shows 500 errors, and when looking at network requests there is a 200 request for the schema in the topic but 404 errors attempting to fetch the topic's schema references (if the schema references require URL path escaping - i.e. %2F for /).

Steps to reproduce

• Configure a schema registry for a Protobuf topic (i.e. some-topic-value) which has one or more references with / in their names.
• Configure the console with a valid schemaRegistry and a non-default server -> basePath.
• Attempt to access 'Schema Registry' on the navigation on the left or attempt to produce a record to a schema registry enabled topic.

Suggested Fix

The problem appears to be related to the middleware which is responsible for stripping the basePath from incoming requests:

console/backend/pkg/api/middlewares.go

Lines 75 to 82 in 8a65264

	// Strip prefix from the request url
	var path string
	rctx := chi.RouteContext(r.Context())
	if rctx.RoutePath != "" {
	path = rctx.RoutePath
	} else {
	path = r.URL.Path
	}

This section of code needs to use the r.URL.RawPath (if present) to build the rctx.RoutePath, not the r.URL.Path. Here's an example middleware from Chi: https://github.com/go-chi/chi/blob/6ceb498b221efa11f559602beb2463b8b52c2161/middleware/clean_path.go#L18-L22. It should probably also remove the prefix from RawPath as well for consistency.

I'm happy to raise a PR with the suggested fix.

[weeco]

Hey @pkwarren , thanks for the detailed report and your analysis. I'm wondering what Console version you are running?

In the past we already had issues with subjects that require URL encoding, but I'm certain that we resolved these for the schema registry pages. We haven't specifically tested with URL rewriting though. Whenever URL encoding is needed (like the slash) it should be replaced by %2F (as you already mentioned). Therefore, I think the middleware shouldn't find more slashes than usual?

[pkwarren]

Hey @pkwarren , thanks for the detailed report and your analysis. I'm wondering what Console version you are running?

Seeing this with v2.7.2 - I also checked latest master and it doesn't appear to have a fix.

In the past we already had issues with subjects that require URL encoding, but I'm certain that we resolved these for the schema registry pages. We haven't specifically tested with URL rewriting though. Whenever URL encoding is needed (like the slash) it should be replaced by %2F (as you already mentioned). Therefore, I think the middleware shouldn't find more slashes than usual?

Yes we are only able to reproduce this with URL rewriting. With the default basePath, everything works great.

[weeco]

Could you check the network request coming from the frontend and whether the subject is actually requested in an encoded form (i.e. slashes in subjectname encoded)?

[pkwarren]

Could you check the network request coming from the frontend and whether the subject is actually requested in an encoded form (i.e. slashes in subjectname encoded)?

Yes it is - the subject in network inspector is path encoded. I've also reproduced from the command line with curl.

[weeco]

Thanks for the info. Maybe you are right with the middleware - the URL path may be decoded too early and slashes will be removed there. If you could come up with a PR that would be great