Accessing User and Certificate config from ApiControllerBase

Started by engelant, August 29, 2019, 08:02:11 PM

Previous topic - Next topic
I'm currently trying to get certificates from OPNsense via the API. As there are no APIs provided to access the Trust store I had the idea of simply creating a user with API key for every client that needs to get a cert, assign the required cert as one of the "User Certificates" and introduce a new System Privilege "API - Allow own certificate/key download".

I get the API and API permission related stuff to work, but I have no clue how to access the user and cert model properly.
What I now would need to do is to get the user ($this->logged_in_user from ApiControllerBase), with which I could get user certificates for that user. With that cert refid(s) I can get descr, crt, prv and caref and that's it.

Problem is, after $this->logged_in_user I have no idea which Model/Controller to call to get my desired data. Can somebody help out?

certificates are legacy code and not api enabled, sorry.
Maybe ... *maybe* ... you could write a fake plugin which is MVC enabled and takes certificates from config, e.g. like FreeRADIUS plugin. But there wont be a user separation.

I noticed that It's old API. My idea was to access the data as direct from the config as necessary.
What would be the recommended way to read the config without a Controller/Model being availible?

I work with them using the raw config object/array. Just use that one.



Spot on, thanks for the examples. I was able to write my own very first plugin, now to see if my code meets the contribution guidelines.

While unrelated to the issue, anyone knows ho to re-read the ACL.xml? I installed und uninstalled helloworld to refresh, but c'mon. Also, is there a way yet to make the permission appear as "API" instead of "GUI" in the permission assignment table?

I want to join the fun pasting code lines :)

https://github.com/opnsense/core/blob/master/src/etc/rc.configure_firmware#L54

We don't have API permissions. With the MVC code we try to cluster GUI access with API access as the GUI parts need the API anyway and so you end up with a use case instead of per-page/action permissions. There's no downside to having GUI access for API only scripts.

EDIT: Maybe as a historical reference "GUI" in the permission merely means it's not a "User" permission which we've tried to remove and I think there is only one left so "GUI" prefix will be removed in an upcoming release to avoid further confusion.

But you can always decide to have API-only permissions in your plugin. In this case the GUI is a bit off in its interpretation until said "User" permission is removed.

Cheers,
Franco