* replace GetAllPages with InitialSync, improve merge performance
* fmt proto
* add test for base64 function
* add sync test
* go mod tidy
Co-authored-by: Bobby DeSimone <bobbydesimone@gmail.com>
Currently, when option changes, whether the option is good or bad, we
always store new policy evaluator.
When options is bad, policy evaluator will be nil. That can lead to panic
at runtime if a Check request were called after Authorize.OnConfigChange
ran with bad option.
We already have an error message if new policy evaluator fails, so we
must only update it on success only.
* authorize: derive check response message from reply message
While at it, add tests for ok response related functions.
* authorize: more test case for ok reply with k8s svc
* store directory groups separate from directory users
* fix group lookup, azure display name
* remove fields restriction
* fix test
* also support email
* use Email as name for google'
* remove changed file
* show groups on dashboard
* fix test
* re-add accidentally removed code
In #1030, the fix was done without aware of the context that traefik
forward auth mode did allow request without the "?uri=". Previosuly,
this is done in proxy, and by converting the forward auth request to
actual request. The fix is #1030 prevent this conversion, to makre
authorize service aware of which is forward auth request.
But that causes traefik forward auth without "?uri" stop working. Fixing
it by making the authorize service also honor the forwarded uri header,
too.
Fixes#1096
Currently, with impersonated request, the real user email/group still
has effects.
Example:
data.route_policies as [{
"source": "example.com",
"allowed_users": ["x@example.com"]
}] with
input.databroker_data as {
"session": {
"user_id": "user1"
},
"user": {
"email": "x@example.com"
}
} with
input.http as { "url": "http://example.com" } with
input.session as { "id": "session1", "impersonate_email": "y@example.com" }
Here user "x@example.com" is allowed, but was impersonated as
"y@example.com". As the rules indicated, the request must be denied,
because it only allows "x@example.com", not "y@example.com". The current
bug causes the request is still allowed.
To fix it, when evaluates rules for allowed email/group/domain, we must checking
that the impersonate email/groups is not set/empty.
Fixes#1091
* add google cloud serverless support
* force ipv4 for google cloud serverless
* disable long line linting
* fix destination hostname
* add test
* add support for service accounts
* fix utc time in test
