[MXS-4232] FR: allow for a 2nd password param for seamless changes Created: 2022-08-03 Updated: 2023-06-02 Resolved: 2023-06-02 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Authenticator |
| Affects Version/s: | None |
| Fix Version/s: | 23.08.0 |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Hartmut Holzgraefe | Assignee: | Johan Wikman |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Sprint: | MXS-SPRINT-183 | ||||||||
| Description |
|
For a more seamless password changing procedure it would be nice to be able to temporarily set two passwords for a server, so that you could do:
This way maxscale config change would not need to be perfectly synced with the password change on the server side, maxscale could continue to try the old password first, and the new one on failure of the old one, or vice versa, or always try the one that succeeded on the previous attempt so that only one login failure due to wrong password would happen. Especially when having multiple maxscale instances there might be a significant time window for the complete password change rollout, and this way we could guarantee that it would still work without any outages. |
| Comments |
| Comment by markus makela [ 2022-08-29 ] |
|
Instead of having multiple explicit passwords, just storing the latest working password in memory might work. This also ties in with |
| Comment by Johan Wikman [ 2023-06-01 ] |
|
This functionality is provided so that MaxScale will remember the previous password (not persistently, but at runtime) and if authentication using the current password fails, it will retry using the previous password, if one is present. Consequently, the procedure for changing the password will simply involve the following steps
The documentation is available here: https://github.com/mariadb-corporation/MaxScale/blob/develop/Documentation/Getting-Started/Configuration-Guide.md#user-and-password |