Skip to content

Conversation

@matej-g
Copy link
Contributor

@matej-g matej-g commented Feb 8, 2022

When working with rules API, the response message is not always very useful for the user. I suggest to:

  • If we don't have any rules stored for the tenant, return message saying no rules found instead of 'error loading rule'
  • If (un)marshalling fails, provide the error in the response. This is useful in particular if the error message including line number, which can be helpful for the user during troubleshooting.

saswatamcode
saswatamcode previously approved these changes Feb 8, 2022
Copy link
Member

@saswatamcode saswatamcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This makes sense! 🙂

Just need to fix lint! But we ran across this again. Worth making an issue?

if err != nil {
level.Error(rh.logger).Log("msg", "could not unmarshal rules", "err", err.Error())
http.Error(w, "error unmarshaling rules", http.StatusInternalServerError)
http.Error(w, fmt.Sprintf("error unmarshaling rules: %v", err), http.StatusInternalServerError)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We normally don't want to return arbitrary errors to the user from API. We don't do this (AFAIK) anywhere in Observatorium or other projects because it raises the possibility of injection attacks where users trigger a known error to get the API to construct a reply with an injected value, which can later be exploited.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, it's our convention to not echo untrusted values back to users

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is any convention, then I wasn't aware of it, we seem to return unknown error in at least a couple other places in the API (e.g. in labels enforcer). But I understand this can have potential security implications. I'm happy to defer this until #234, in which (in ideal case) we should be able to establish cause of error and potentially return more details to user, since current message is not very helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 👍 I removed this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 👍 I removed this change.

.PHONY: test-e2e
test-e2e: container-test
CGO_ENABLED=1 GO111MODULE=on go test -v -race -short --tags integration ./test/e2e
@rm -rf test/e2e/e2e_*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! 👾

@matej-g matej-g requested review from jessicalins and squat February 11, 2022 09:57
"github.com/efficientgo/tools/core/pkg/testutil"
)

const recordingRuleYamlTpl = `
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to make the e2e tests pass we need now to update this const as in here
after that LGTM :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, missed this during merge conflict, thank you 🙇

squat
squat previously approved these changes Feb 11, 2022
Signed-off-by: Matej Gera <[email protected]>
Copy link
Contributor

@jessicalins jessicalins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍉

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

Successfully merging this pull request may close these issues.

4 participants