Attempts to reduce some of the boilerplate required to marshal a
resource by moving common resource idenfitier handling to a utility
method. This currently only works for resources that are proto in
nature and not plain structs(access lists, secreports, discovery
config, etc.).
* Introduce scaffolding for access list Slack notification.
The initial scaffolding for notification of the need for reviews for access
lists has been introduced. This is not expected to do anything just yet, but
will do so in a follow on PR.
This has additionally separated the plugin data from the dynamic access core,
as it no longer is tightly coupled to access requests. No effort was made to
refactor the existing plugin data backend logic.
* Ensure that the context is cancelled on process termination.
* Remove debug hour addition.
* Correct notification date calcs, add test for notifications.
* Expire the access list after two weeks, use a single map instead of multiple plugin data keys.
* Run GCI.
* Tune tests, retry period is now a duration.
* Get rid of gocron, use intervals, test using intervals.
* GCI.
* Renames, test tweaks.
* Refactor access plugins.
* GCI.
* Adjust tests, remove generics, plugin data uses JSON marshal instead of custom marshaling.
* Move recipient back to common.
* Missed a few recipients imports.
* Tweaks to logic, auto registration of apps, commenting and cleanup.
* Prevent blank revisions from being read from the backend
Overwrites any empty resource revisions with a placeholder value to
prevent any blank revisions from being provided to users.
* Prevent backend items with empty revisions
All resource revisions are now being set on a backend.Item before
persisting the item to the backend.
* Set revision on resources retrieved from the backend
Adds a new `MarshalOption` that ensures the resource revision is
set when unmarshalling a backend item. The new `WithRevision` option
was also applied everywhere that the legacy `WithResourceID` was
being used.
* Prevent storing resource revision in the backend item value
The revision follows the same semantics as the resource id for
marshalling. This prevents both items from showing up in the value
of the backend item, which can prevent compare and swap operations
from completing succesfully. Each backend is responsible for
persisting the revision in some manner.
The existing PreserveResourceID was reused to prevent having to
make multiple copies of a resource when clearing the id and revision.
The marshal option will be updated in a follow up when the resource
id is removed.
* Ignore revision in resource comparisons
Update metalinter, fix a few lint warnings and replace deprecated linters.
`deadcode`, `structcheck` and `varcheck` are abandoned and now replaced by [`unused`][1].
Since 1.19, `go fmt` reformats godocs according to https://go.dev/doc/comment. I've done a bulk-reformatting of the codebase to keep the linter happy. Backporting is mostly harmless (the exception being `lib/services/role_test.go`, that for some reason breaks the _old_ linter using the new format).
[1]: https://golangci-lint.run/usage/linters/
* Bump golangci-lint version
* Replace abandoned linters
* Fix bodyclose on lib/auth/github.com
* Fix bodyclose on lib/kube/proxy/streamproto/proto_test.go
* Fix bodyclose on lib/srv/alpnproxy/proxy_test.go
* Fix bodyclose on lib/web/conn_upgrade_test.go
* Silence staticcheck on lib/kube/proxy/forwarder_test.go
* Silence staticcheck on lib/utils/certs_test.go
* Address BuildNameToCertificate deprecation warnings
* Run `go fmt ./...`
* Run `go fmt ./...` on api/
* Ignore formatting in role_test.go
* Remove redundant initializers in lib/srv/uacc/
* Update e/
* Remove JSON schema validation
Removing JSON schema validation from all resource unmarshalers.
--- what JSON schema gets us
Looking at the JSON schema spec and our usage, here are the supposed benefits:
- type validation - make sure incoming data uses the right types for the right fields
- required fields - make sure that mandatory fields are set
- defaulting - set defaults for fields
- documentation - schema definition for our API objects
Note that it does _not_ do:
- fail on unknown fields in data
- fail on a required field with an empty value
--- what replaces it
Based on the above, it may seem like JSON schema provides value.
But it's not the case, let's break it down one by one:
- type validation - unmarshaling JSON into a typed Go struct does this
- required fields - only checks that the field was provided, doesn't actually check that a value is set (e.g. `"name": ""` will pass the `required` check)
- so it's pretty useless for any real validation
- and we already have a separate place for proper validation - `CheckAndSetDefaults` methods
- defaulting - done in `CheckAndSetDefaults` methods
- `Version` is the only annoying field, had to add it in a bunch of objects
- documentation - protobuf definitions are the source of truth for our API schema
--- the benefits
- performance - schema validation does a few rounds of `json.Marshal/Unmarshal` in addition to actual validation; now we simply skip all that
- maintenance - no need to keep protobuf and JSON schema definitions in sync anymore
- creating new API objects - one error-prone step removed
- (future) fewer dependencies - we can _almost_ remove the Go libraries for schema validation (one transient dependency keeping them around)
* Remove services.SkipValidation
No more JSON schema validation so this option is a noop.
Forrest