long-term viability

[travisghansen]

To support the long-term viability of the project we likely need to gradually migrate away from xmlrpc and entirely deprecate the xmlrpc client.

To facilitate that a helpful change would be to allow the api key/secrets to be used as username/password for the xmlrpc calls. This would allow a single set of credentials to service both xmlrpc and REST calls simultaneously during the transition period.

[alexdelprete]

I fiddled with the API with Postman, and I used the api key/secret as user/pw for basic authentication. So creating a user with user/pw exactly the same as the API user/pw should work, right?

[travisghansen]

My tests showed api keys/secrets don't work as the username/password for the xmlrpc api. I could have messed something up though.

[alexdelprete]

I read this:

So if you create API key/secret, then create a user with user=key and pw=secret, I don't see why it wouldn't work. It's two different auths, but with the same set of credentials. Probably when you created the user there was some problem.

[travisghansen]

For some reason I was thinking the interface name was part of it. I’m generally in favor of being more expressive with naming but we can take a look.

[alexdelprete]

This is how an entity for filter rule looks like in HA:

And the code in fact is using created.time for both key and name of the entity:

                    tracker = dict_get(rule, "created.time")
                    if tracker is None:
                        continue

                    # we use tracker as the unique id
                    if len(tracker) < 1:
                        continue

                    entity = OPNSenseFilterSwitch(
                        config_entry,
                        coordinator,
                        SwitchEntityDescription(
                            key="filter.{}".format(tracker),
                            name="Filter Rule {} ({})".format(tracker, rule["descr"]),
                            icon=icon,
                            # entity_category=entity_category,
                            device_class=device_class,
                            entity_registry_enabled_default=enabled_default,
                        ),
                    )
                    entities.append(entity)

[travisghansen]

Yeah I think it makes sense to add the interface in the very front. I’d need to see how ‘floating’ rules look though.

[alexdelprete]

you could do a check if interface is empty and replace with "floating". So we also know it's a floating one. :)

obviously, if that is the proper way to identify floating rules...I have to check...

CHECKED: can't find floating rules in config...where does it create them from?

[alexdelprete]

I'm sure there's other data I had to remove but don't recall what all the datapoints were. In the broader sense to support the long-term viability there's really 2 things:

1. build out the functions/data in the OPNsense internals
2. expose all of via the REST api

If 1 is done before 2 then I can use the xmlrpc feature to grab the data immediately and use it even before the REST api supports it.

@fichtner Franco, sorry to ping you again, I know you're busy, but it would really be important having your advice about Travis's post I quoted above.

Basically it seems there's no structured methods to retrieve all the info that could be pulled out for some datapoints (I was asking about DHCP leases, etc.). We looked at the REST API but it doesn't seem to be available. So we wanted to know what would be the best path, in your valuable opinion...

Thanks a lot for your help.