Commit graph

6 commits

Author SHA1 Message Date
Joey Orlando
9e598385f4
Add RBAC Support (#777)
* Modify plugin.json to support RBAC role registration

* defines 26 new custom roles in plugin.json. The main roles are:

- Admin: read/write access to everything in OnCall
- Reader: read access to everything in OnCall
- OnCaller : read access to everything in OnCall + edit access to Alert Groups and Schedules
- <object-type> Editor: read/write access to everything related to <object-type>
- <object-type> Reader: read access for <object-type>
- User Settings Admin: read/write access to all user's settings, not just own settings. This is in comparison to User Settings Editor which can only read/write own settings

* update changelog and documentation (#686)

* implement RBAC for OnCall backend

This commit refactors backend authorization. It trys to use RBAC authorization if the org's grafana instance supports it, otherwise it falls back to basic role authorization.

* update RBAC backend tests

* add tests for RBAC changes
- run backend tests as matrix where RBAC is enabled/disabled. When RBAC is enabled, the permissions granted are read from the role grants in the frontend's plugin.json file (instead of relying what we specify in RBACPermission.Permissions)
- remove --reuse-db --nomigrations flags from engine/tox.ini
- minor autoformatting changes to docker-compose-developer.yml

* remove --ds=settings.ci-test from pytest CI command

DJANGO_SETTINGS_MODULE is already specified as an env var so this is just unecessary duplication

* update gitignore

* update github action job name for "test"

* RBAC frontend changes

* refactors the use of basic roles (ex. Viewer, Editor, Admin) use RBAC permissions (when supported), or falling back to basic roles when RBAC is not supported.

- updates the UserAction enum in grafana-plugin/src/state/userAction.ts. Previously this was hardcoded to a list of strings that were being returned by the OnCall API. Now the values here correspond to the permissions in plugin.json (plus a fallback role)

* changes per Gabriel's comments:
- get rid of group attribute in rbac roles
- remove displayName role attribute
- remove hidden role attribute
- add back role to includes section

* don't try to update user timezone if they don't have permission
2022-11-29 09:41:56 +01:00
Michael Derynck
3582f9b08f
Improve Jinja Template feedback and error handling (#884)
* Improve feedback so template errors are given to user

* Add security error logging

* Add limits for templates, payloads, results

* Show popup error notification for webhook errors and template errors that don't have a result

* Update tests

* Split exceptions into warnings/errors to give more control when previewing, rendering, saving templates

* Limit title lengths

* Make TypeError a warning

* Adjust title length limit

* Remove length limiting on urlize since it is being done on template render

* Fix tests

* Add KeyError and ValueError to warnings

* No longer enforcing json result when saving webhook in case it is dependent on payload

* Add tests for expected exceptions coming from apply_jinja_template

* Update changelog

* Send raw post if template result is not JSON
2022-11-28 09:46:51 -07:00
Joey Orlando
5a4c3d6d77
remove POST /api/internal/v1/custom_buttons/{id}/action (#734)
* remove POST /api/internal/v1/custom_buttons/{id}/action
2022-10-28 10:44:37 +02:00
Ben Sully
e36757b293
Allow non-JSON custom webhook templates, provided they render as valid JSON (#639)
* Allow non-JSON custom webhook templates, provided they render as valid JSON

Previously, both the provided template _and_ the rendered template had
to be valid JSON in order for validation to pass. This was unnecessarily
restrictive: really, only the rendered template needs to be valid JSON.
It also disallowed using templates such as:

    {
      "labels": {{ alert_payload.labels | tojson }}
    }

even though this would be valid JSON after rendering.

This commit relaxes the validation of custom webhook templates so that
they don't need to be valid JSON, provided that the rendered template
_is_ valid JSON. This is checked using a dummy dictionary of render
params, which use a constant string for the `alert_group_id` field
and a `defaultdict(dict)` for the `alert_payload` field. This should
permit templates like the one above, but still deny templates such as

    {
      "labels": {{ alert_payload.labels }}
    }

which would otherwise fail later if `labels` is not valid JSON.

This should resolve #638.

* Use defaultdict(str) instead of defaultdict(lambda: "")

* Add missing comment to resolution note validation code

* Update validation of resolution notes in public API, too

* Add extra test cases for JSON webhook templates endpoint of public API
2022-10-19 12:32:21 +01:00
Julia
e4ae10c678 Wrong team error for schedules and custom buttons, add flag to get object from the whole organization 2022-09-12 17:26:23 +03:00
Michael Derynck
6b40f95033 World, meet OnCall!
Co-authored-by: Eve832 <eve.meelan@grafana.com>
    Co-authored-by: Francisco Montes de Oca <nevermind89x@gmail.com>
    Co-authored-by: Ildar Iskhakov <ildar.iskhakov@grafana.com>
    Co-authored-by: Innokentii Konstantinov <innokenty.konstantinov@grafana.com>
    Co-authored-by: Julia <ferril.darkdiver@gmail.com>
    Co-authored-by: maskin25 <kengurek@gmail.com>
    Co-authored-by: Matias Bordese <mbordese@gmail.com>
    Co-authored-by: Matvey Kukuy <motakuk@gmail.com>
    Co-authored-by: Michael Derynck <michael.derynck@grafana.com>
    Co-authored-by: Richard Hartmann <richih@richih.org>
    Co-authored-by: Robby Milo <robbymilo@fastmail.com>
    Co-authored-by: Timur Olzhabayev <timur.olzhabayev@grafana.com>
    Co-authored-by: Vadim Stepanov <vadimkerr@gmail.com>
    Co-authored-by: Yulia Shanyrova <yulia.shanyrova@grafana.com>
2022-06-03 08:09:47 -06:00