Implement consul config for permission-mapping and config fallback #23
Labels
No labels
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Support
Type
Task
Type
Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
You do not have permission to read 1 dependency
#29 Implement consul config permission mapping resolving with fallback to application yaml
clevermicro/user-management
Reference: clevermicro/user-management#23
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently the permission-mapping is stored in the
application.yml
, which is packaged in the distributed jar file. The permission mapping gives instructions to auth-service on how to map the URL to an OIDC client, and for the future, we may have more config that is dynamic and frequently updated to meet the services' need (for example, pass through certain url for api access).This ticket will implement the consul config, and use the value from consul for permission mapping. If the consul is not available (either going down or something is broken), then the application should fall back to the default configuration included in the
application.yml
with a minimal set of configurations that allows human to access the clevermicro services to debug and fix the system (no third party services included). Right now we don't have other clevermicro services that require auth protection, so the config inapplication.yaml
should only contain auth-service itself.