bunkerity / bunkerity/bunkerweb
[FEATURE] Add Description or Note Fields for IP and Network Entries in White-, Grey-, and Blacklists
- Dominant language
- Python
- Stars
- 10.9k
- Forks
- 643
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 42
Description
### What's needed and why?
### Problem Statement
In BunkerWeb, users can define IP addresses or networks globally or per service in the whitelist, greylist, and blacklist. While this works well functionally, it becomes difficult to manage over time, especially in larger setups.
A common issue is that users may no longer remember what a specific IP address or network belongs to, why it was added, or which system, customer, service, or location it represents. This becomes even more difficult when both IPv4 and IPv6 entries are used, as the entries are often not self-explanatory.
Without additional context, these lists can quickly become hard to maintain, audit, and review. This increases the risk of outdated or incorrect entries remaining in place simply because their purpose is no longer clear.
### Proposed Solution
Add the ability to define an optional description or note for each individual IP address or network entry in the whitelist, greylist, and blacklist, both globally and per service.
For example, each entry could include:
- the IP address or network
- an optional label, note, or description
- possibly a short purpose such as “Office VPN”, “Monitoring Server”, “Customer Gateway”, or “Temporary block for abuse case”
This would allow users to assign clear meaning and ownership to each entry, making the lists much easier to understand and maintain.
### Expected Benefit
This feature would improve:
- readability of IP and network lists
- long-term maintainability
- auditability and troubleshooting
- clarity when working with mixed IPv4 and IPv6 environments
It would make access control entries much more manageable, especially for users operating larger or more complex BunkerWeb deployments.
### Implementations ideas (optional)
_No response_
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Contributor guide
Research direction
No implementation files, tests, or entry points are identified. Start by locating how global and per-service whitelist, greylist, and blacklist entries are defined and consumed. Done means optional descriptions are supported for individual IP or network entries in all three lists and both scopes, with the expected configuration and display behavior clarified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100