To interact with WordPress API, instead of using user / password, you can use oauth2.
It’s considered the right way to use remote APIs. The provider, word press in this case, validates the user, and you, as the application, only knows about a token.
Anyway, you have to store the token in a secure place.
Another option is the usage of an API key, a la AWS CLI, but I don’t think it is supported by WordPress (you avoid the burden of oauth2 login, Chevy, redirect,…) .
It doesn’t look like WordPress core supports Oauth2. I’m just using the Rest API there, so only looking for a minimal working setup as I need to learn Lua in addition of whispering to unknown API’s ears. But storing passwords in clear text somewhere is something I would prefer to avoid.
So the connection providers that once provided login to Facebook and Flickr were all coded in C ?
The facebook, flickr and google interfaces were all removed because the yearly release cycle of darktable couldn’t keep pace with the API changes, so the storages were broken most of the time. The thought process was to rebuild them in the lua-scripts since it’s not tied to a release schedule in the hopes it could keep up with the API changes.
All of those storages face the same authentication problem that wordpress does, i.e. how to store credentials and access them and then authenticate to <something>.
The good news is that we control the lua API in darktable, so we can leverage the existing credential storage code by extending the API to use it. On the lua side we probably need to code up an authentication library to take care of accessing various services.
I’ll look at the existing c code and start figuring out how to extend the API.