Files
grafana/pkg
Sofia Papagiannaki dc9ec7dc91 Auth: Allow expiration of API keys (#17678)
* Modify backend to allow expiration of API Keys

* Add middleware test for expired api keys

* Modify frontend to enable expiration of API Keys

* Fix frontend tests

* Fix migration and add index for `expires` field

* Add api key tests for database access

* Substitude time.Now() by a mock for test usage

* Front-end modifications

* Change input label to `Time to live`
* Change input behavior to comply with the other similar
* Add tooltip

* Modify AddApiKey api call response

Expiration should be *time.Time instead of string

* Present expiration date in the selected timezone

* Use kbn for transforming intervals to seconds

* Use `assert` library for tests

* Frontend fixes

Add checks for empty/undefined/null values

* Change expires column from datetime to integer

* Restrict api key duration input

It should be interval not number

* AddApiKey must complain if SecondsToLive is negative

* Declare ErrInvalidApiKeyExpiration

* Move configuration to auth section

* Update docs

* Eliminate alias for models in modified files

* Omit expiration from api response if empty

* Eliminate Goconvey from test file

* Fix test

Do not sleep, use mocked timeNow() instead

* Remove index for expires from api_key table

The index should be anyway on both org_id and expires fields.
However this commit eliminates completely the index for now
since not many rows are expected to be in this table.

* Use getTimeZone function

* Minor change in api key listing

The frontend should display a message instead of empty string
if the key does not expire.
2019-06-26 09:47:03 +03:00
..
2019-06-04 22:00:05 +02:00
2019-06-13 16:47:51 +02:00

Grafana backend codebase

The code styleguide and brief description of the architecture

On going refactorings.

These issues are not something we want to address all at once but something we will improve over time. Since Grafana is released at a regular schedule the prefer approuch is to do this in batches. Not only is it easier to review, it also reduces the risk of conflicts when cherry-picking fixes from master to release branches. Changes that spawn multiple locations are therefore prefered in the end of the release cycle since we make fewer patch releases in the end of the cycle.

Global state

Global state makes testing and debugging software harder and its something we want to avoid when possible. Unfortunately, there is quite a lot of global state in Grafana. The way we want to migrate away from this is to use the inject package to wire up all dependencies either in pkg/cmd/grafana-server/main.go or self registering using registry.RegisterService ex https://github.com/grafana/grafana/blob/master/pkg/services/cleanup/cleanup.go#L25

Reduce the use of the init() function

Should only be used to register services/implementations.

Settings refactoring

The plan is to move all settings to from package level vars in settings package to the setting.Cfg struct. To access the settings services/components can inject this setting.Cfg struct.

Cfg struct Injection example

Reduce the use of Goconvey

We want to migrated away from using Goconvey and use stdlib testing as its the most common approuch in the GO community and we think it will make it easier for new contributors. Read more about how we want to write tests in the ARCHITECTURE.MD docs.

Sqlstore refactoring

The sqlstore handlers all use a global xorm engine variable. This should be refactored to use the Sqlstore instance.

Avoid global HTTP Handler functions

HTTP handlers should be refactored to so the handler methods are on the HttpServer instance or a more detailed handler struct. E.g (AuthHandler). This way they get access to HttpServer service dependencies (& Cfg object) and can avoid global state

Date comparison

Newly introduced date columns in the database should be stored as epochs if date comparison is required. This permits to have a unifed approach for comparing dates against all the supported databases instead of handling seperately each one of them. In addition to this, by comparing epochs error pruning transformations from/to other time zones are no more needed.

Dependency management

The Grafana project uses Go modules to manage dependencies on external packages. This requires a working Go environment with version 1.11 or greater installed.

All dependencies are vendored in the vendor/ directory.

Note: Since most developers of Grafana still use the GOPATH we need to specify GO111MODULE=on to make go mod and got get work as intended. If you have setup Grafana outside of the GOPATH on your machine you can skip GO111MODULE=on when running the commands below.

To add or update a new dependency, use the go get command:

# The GO111MODULE variable can be omitted when the code isn't located in GOPATH.
# Pick the latest tagged release.
GO111MODULE=on go get example.com/some/module/pkg

# Pick a specific version.
GO111MODULE=on go get example.com/some/module/pkg@vX.Y.Z

Tidy up the go.mod and go.sum files and copy the new/updated dependency to the vendor/ directory:

# The GO111MODULE variable can be omitted when the code isn't located in GOPATH.
GO111MODULE=on go mod tidy

GO111MODULE=on go mod vendor

You have to commit the changes to go.mod, go.sum and the vendor/ directory before submitting the pull request.