existing certificates during both manual and automatic renewals.
-Enhance filtering and normalization of domain names from the UI
to ensure only valid domains are included when requesting certificates.
Updated the ReverseProxy's ProxyHTTPS method to use tls.Dial with SNI support when connecting to upstream servers. Also incremented SYSTEM_VERSION to 3.2.7.
- Reorganized HTTP mux initialization to clarify plugin and webmin UI routing, replacing parentMux with entryMux.
- Fixed typo in ReverseProxyInit function name and updated its usage in main.go.
The only thing left is to add an API endpoint for broadcasting
EventCustom events (other event types should not be emittible by
plugins, the use-case isn't there since plugins can already talk to
Zoraxy via the API).
Input to the endput should be a json-encoded `CustomEvent`
this design (as opposed to adding a Source field to the Event struct)
requires fewer changes to existing APIs while still supporting the two
primary cases for event sources:
1. an event that always has the same source can just return a hard-coded
string
2. an event that can come from multiple components (or from plugins) can
have a source field that gets returned by this function
The import, when the code is copied to develop a plugin, results an invalid path.
Fixing the path manually as a plugin developer is easy, but it shouldn't be necessary.
To fix that, the type is replaced with a string in zoraxy_plugin.IntroSpect and validation is added to lifecycle.go to ensure all subscribed events are valid.
A downside is that the list of validEventNames has to be updated whenever a new event is created, but this is mitigated by placing definitions of that list and the actual event names right next to each other.
This implements a minor modification to the forward authz sso where the body can be copied to the auth server and the X-Original-* implementations can be used.
Implements the partially created event system with 3 events implemented as proof of concepts.
The 3 events are:
- `blacklistedIpBlocked`: emitted when a request from a blacklisted IP
- `accessRuleCreated`: emitted when a new access rule is created
- `blacklistToggled`: emitted when the blacklist is toggled for a given access rule
Why these events? Because these are the ones I forsee myself needing in the next version of the zoraxy_crowdsec_bouncer
Events are dispatched via a global event manager `plugins.EventSystem.Emit`
