API access to firewall rules and aliases #1858
Comments
|
It's on the roadmap, but long time, since we need the legacy code to move into manageable direction, this #1326 for example is a prerequisite and then we should move all validations into a model/controller construction. A possible short-term win could be to add an api to the aliases and start from there, for most scenarios access to the aliases is enough (like fail2ban), less validations there and less attributes to worry about. Still quite some work, but fits the roadmap. |
|
Well, I'm for anything that allows me to update aliases from an API :). Is this something that has to be sponsored? I don't know if I have the skillset to help programmatically... |
|
I’m working in that area, but very busy. I’ll put it on my list of things todo, maybe 18.1, I can’t promise |
…rm fetch code and our standard templates, when specified in the form a data tag separator wil be added, which is used to render the results in getFormData(). In some cases it can be practical if something else then a comma can be used to split fields. slightly related to #1858.
…rm fetch code and our standard templates, when specified in the form a data tag separator wil be added, which is used to render the results in getFormData(). In some cases it can be practical if something else then a comma can be used to split fields. slightly related to opnsense/core#1858.
…entually combine the different validations for the supported alias types.
…ich should eventually combine the different validations for the supported alias types.
…egacy code base, needed for #1858 We probably could also use filter_var here, but while shifting to new code it's probably better to align the logic to avoid searching for inconsistencies after migration.
(cherry picked from commit a14378c)
…hange event to support custom hooks, a bit related to #1858
…a and expects the callback to filter them, which forces us to include the fieldname in the validator to prevent feeding the wrong results. for #1858
…egacy code base, needed for opnsense/core#1858 We probably could also use filter_var here, but while shifting to new code it's probably better to align the logic to avoid searching for inconsistencies after migration.
…no description is provided in get_alias_description(). closes #2495
… the migration inactive for the time being. (cherry picked from commit eeb14c2)
|
Tested new aliases in current master. Why don't you display "content" in the overview? It's quite unusual when you have a huge list but no IP addresses in overview volt listed. |
|
|
|
@mimugmail content can be quite large (and usually is), but we probably can add the first x items there |
|
Indeed, but as you can see from the screenshot it looks a bit odd compared to legacy code |
|
@mimugmail e42c3d2 should do the trick |
|
Looks good, thanks 👍 |
|
Except for final merge date we are all done here with a bonus MVC rework on top for table diagnostics page. :) Great work by @AdSchellevis |
|
First upgrades in a couple of systems went smoothly. Very nice work @AdSchellevis ..very appreciated :) |
|
@mimugmail thanks! |
|
yes, thanks @AdSchellevis ❤️ |
|
hey @AdSchellevis is there a documentation of your API? ...I stummbled around in the user / development manual and only came up to this thanks for any hint! |
|
@vlabmichl the general concept is found here https://docs.opnsense.org/development/how-tos/api.html best use the inspector in your browser to find the exact payload for an endpoint (all endpoints are used in the alias page and diagnostics -> pfTables). |
Definition
As a user, I need API access to update firewall aliases and rules. The specific use case is to run an agent on my servers (fail2ban for instance), that can update a firewall alias list with banned IP addresses for the firewall rule/s.
Next Steps
Not sure how to get started on such a thing... Also, please let me know if this is a duplicate of an existing issue.
The text was updated successfully, but these errors were encountered: