- notification management
- dont notify when NOT_RECOVERED_BLOCK is on
- clean up & fixes
- improve tests
Original commit: elastic/x-pack-elasticsearch@907af6d308
Now it logs the failure on debug and on trace it also logs the full stack trace. There's no point in logging it on info as a lot of the failures that will be logged are just fine (e.g. esusers will fail to authenticate and log the failure, but LDAP will succeed). This logging should only be applied for debugging purposes... for normal logging we have the audit logs
While at it, also cleaned up the Ldap realm code... change java.lang.SecurityException to shield's LdapException
Closeselastic/elasticsearch#281
Original commit: elastic/x-pack-elasticsearch@d5f0ad2efb
- Changed the behaviour of esusers realm so that whenever the `users` or the `users_roles` file are updated, the realm's cache expunges
- Changed LDAP realm such that when the `role_mapping.yml` file is updated, the realm's cache expunges
Also, cleaned up unused code (mainly around esusers and the different stores)
Original commit: elastic/x-pack-elasticsearch@3f093207da
This change adds the AlertActionManager and AlertActionEntry. The old AlertActionManager has become the AlertActionRegistry.
This means that now the results of Alerts are queued up in a job queue and executed in separate threads.
The AlertActionManager is a composite member of the AlertManager.
Change the BasicTest to just run on a single node to fix the action registration if the action happens on a different node.
Threads are not directly constructed but now the threadpool is used.
The ClusterStateListener in AlertManager is responsible now for starting the job queue.
Original commit: elastic/x-pack-elasticsearch@a73c6b60f8
Fixes a bug where the wrong exception and wrong error status code (500) were returned when the user sent the wrong username/password. This fixes this beahviour to return an `AuhthenticationException` with a 401 status code.
Fixeselastic/elasticsearch#271
Original commit: elastic/x-pack-elasticsearch@0a120caeae
We now moved from the logic of checking `indices:` and `cluster:` prefixes to determine whether an action is an indices or a cluster action... instead we use the index/cluster privielge `all` privilege to determine that (which is more accurate in the context of shield, as it enables us to move actions between the two categories while keeping their logical name intact)
Also updated the docs to reflect that template related actions are infact cluster actions.
Original commit: elastic/x-pack-elasticsearch@8027334105
Added `shield.user` setting so that the clients won't need to go through the unnatural and tedious process of configuring the `Authorization` header directly (that also requires the user to applicat the base64(username:password) logic.
Now, the user can just set the following settings to bind a user to the client:
```yaml
shield.user: 'username:password'
```
Original commit: elastic/x-pack-elasticsearch@94be3abd92