To clarify, I didn’t develop a way to connect the first plugin with the loraserver project (well, initially I did by forking it and adding some features, but then I ditched that). What I developed is another plugin, which you can check at the second github link on my past comment, and it was created to be used with loraserver, lora-app-server and lora-gateway-bridge, though now it accepts a bunch of unrelated backends too.
there were some issues, for example when restarted the machine mosquitto had started and exit. I have to restart mosquitto.service to get the broker on.
That is a known issue with jpmens’ plugin, which @brocaar opened a long time ago: https://github.com/jpmens/mosquitto-auth-plug/issues/269. Basically, mosquitto starts before postgres, the plugin can’t connect and thus mosquitto exits. My plugin resolves this by waiting for a connection on startup (wether it is postgres, mysql or even redis, it doesn’t matter), and then just resuming with initialization once the connection is established.
I am using loraserver_0.20 and lora-app-server_0.11. They are compatible with the project?
Yep, the plugin is meant for mosquitto, so it doesn’t matter which versions of loraserver you are running.
I have to compile inside the machine or there is a way to generate a .deb?
The plugin must be compiled, but there’s a Makefile available that makes it pretty easy, so the process is quite simple: just clone the repository inside your Go path, cd into the directory and run the following commands.
This will get all Go packages dependencies that the plugin needs:
This will build the plugin using Go’s buildmode. Also, it’ll build a utility binary,
pg, which allows to create password hashes for the passwords file:
That’s it! Then you just need to give the path of the generated shared object (go-auth.so) to mosquitto.
I just need to use JWT, postgres and Files just?
Those are exactly the backends that I use for loraserver. Furthermore, jpmens’ plugin only allows JWT option through http, but for loraserver, it makes sense to use the token to get the user claims and directly query the same DB that loraserver uses instead of having to send a request to an API (though it allows it too), which is implemented in my plugin.
Configuration is pretty much the same as the recommended one. All configuration options are duly documented on the repo’s Readme, but -sensible information apart- here’s my configuration to give you an example (it includes redis as a backend too, but just omit it):
auth_opt_backends files, postgres, jwt, redis
auth_opt_pg_userquery select password_hash from "user" where username = $1 and is_active = true limit 1
auth_opt_pg_superquery select count(*) from "user" where username = $1 and is_admin = true
auth_opt_pg_aclquery select distinct 'application/' || a.id || '/#' from "user" u inner join organization_user ou on ou.user_id = u.id inner join organization o on o.id = ou.organization_id inner join application a on a.organization_id = o.id where u.username = $1 and $2 = $2
auth_opt_jwt_userquery select count(*) from "user" where username = $1 and is_active = true limit 1
auth_opt_jwt_superquery select count(*) from "user" where username = $1 and is_admin = true
auth_opt_jwt_aclquery select distinct 'application/' || a.id || '/#' from "user" u inner join organization_user ou on ou.user_id = u.id inner join organization o on o.id = ou.organization_id inner join application a on a.organization_id = o.id where u.username = $1 and $2 = $2
I’d recommend that you take a look at the readme on github to check what the plugin offers and how it works, then just clone and try to use it. If you meet any problems, have any doubts or suggestions, just reply in this topic so I can help you.