Bug: Normalize both url path and capability substring for endpoint authorization

[denopink]

bascule checks wether or not one of the sat token capabilities matches the request url. This works by checking 1) the capabilities like hooks is a subset match of the request url and 2) that match starts at index 0:

where re is the regex for hooks capability and urlToMatch should start with hooks

bascule/basculechecks/endpointchecks.go

Lines 105 to 110 in ef08626

	matchIdxs := re.FindStringIndex(urlToMatch)
	if matchIdxs == nil || matchIdxs[0] != 0 {
	return false
	}
	return true

The issue at hand is that go's net lib may include a leading / in its url path. So urlToMatch would point to /hooks instead of hooks and thus failing the endpoint authorization.

The solution is to normalize both re and urlToMatch to contain a leading / such that the currently logic works.

[JC000]

The responsibility falls on the creators of the capabilities used in the authorization input to use proper regular expressions to contain word boundaries so that this doesn't happen.

[denopink]

@johnabass I don't think we provide a way for a user to configure the regex for comparing these two strings.
Here's the code:

bascule/basculechecks/endpointchecks.go

Lines 100 to 106 in ef08626

	re, err := regexp.Compile(matches[1]) //url regex that capability grants access to
	if err != nil {
	return false
	}
	matchIdxs := re.FindStringIndex(urlToMatch)
	if matchIdxs == nil || matchIdxs[0] != 0 {

If I'm not missing it and we're actually not supporting that functionality atm, then I can add it.
I believe JC has a good point since other anomalies may show up later.

[johnabass]

It's not the regex a user would configure. It's that custom validators can be written to take advantage of what bascule has parsed. We already support that functionality, and we use it in our own software.

[denopink]

closed by #173