API for scripting about wg-portal

[PandemiK911]

Oh yeah ! The swagger doc is really nice !
Let me a couple of days and I'll return a first version of a shell script (to be OS-agnostic) to create/install a peer.

[h44z]

Hi, I have implemented a simple REST API now. (Swagger Documentation: http://<your wg-portal ip/domain>/swagger/index.html)

The interessting endpoints for your usecase are:

• GET /provisioning/peer/{pkey}: retrieve the configuration file for the given public key
• POST /provisioning/peers: create a new peer and return the configuration file
• GET /provisioning/peers/{email}: list all active public keys for the given email

So a sample workflow for some auto-provision script could be:

1. Ask for user credentials
2. GET /provisioning/peers/{email} to list all available public keys
3. Let the user choose one public key, or if no key is available or the user wants to create a new one -> POST /provisioning/peers
4. In case that the user chose an existing key, GET /provisioning/peer/{pkey}
5. Write the response of the POST (3.) or the GET (4.) request to wgX.conf
6. Restart WireGuard

I hope this helps you.

If you write some nice deployment scripts, feel free to contribute them to this project :)

[PandemiK911]

Just got a nice limitation : in WG pubkeys, you can have some forward slashes "/" and AFAIK it can't be used as valid URL as this symbol is used for directory separation.
I tried to get the config file for "l5im6GB5N8hh56fJO6DmbgYKeU/aroNnePAhnuzlQXI=" and I'm always getting a 404 error.

Perhaps could I find a way to ask curl to encode the string into something else but in my point of view, this situation is not desirable.

As a workaround, I think we could encore base64 the pubkey in the URL. It's the simpler method I think of.
Another one would be to pass the pubkey as an arg to the URL ( GET /provisioning/peer/?key=pubkey) but it's not the way you constructed the API.

Any thoughts ?

[h44z]

Base64 encoding won't work (the key is already base64 encoded) as base64 has a / in its allowed charset.
I think using a query parameter like ?key is the simplest solution.

[PandemiK911]

After reading a bit about base64encore and urlencode, we'll still be in trouble with '+' and '=' char in a URL parameter.
Perhaps could it be bypassed by encoding correctly the string in the request (automagically with curl ?) but I still need to read a bit to find the best compromise.

[h44z]

I quickly changed the public key parameter to a query parameter. So there should be no problem any longer. All other parameters still have the same format. I am unsure if I should change all parameters to query parameters in order to get a consistent api...

[PandemiK911]

So far, so good !
I had to use --data-urlencode "pkey=$wgpubkey" in my curl call to get the peer config. I also tested with a pubkey containing '+', it worked too.

About rewriting other endpoint, I think having a consistent api is a good thing. Nobody else should be using this API right now so we can't really call this an incompatible change ;-)
Right now, there's only 'device' and 'email' as used parameters, right ?

I have no clue of the work it suppose, so feel free to do as you prefer, of course.

Right now, the only endpoint I'll be using is /provisioning/peer as POST and GET.

Am I reading wrong or did you add some endpoints in the meantime ? I didn't remember about /bakend/users as POST.

[h44z]

No new backend endpoints here ;)
I changed all url paths now, so one can use query parameters everywhere.

[PandemiK911]

OK, thank you.
Here is a first version of my config-retrieval shell script : https://gitlab.altinea.fr/altinea/install-scripts/src/branch/master/wireguard/wgportal_peer_install.sh

Probably buggy and a few verifications missing.

I took most of the argument parsing code from acme.sh. This should ensure the script is POSIX-compliant and can be used with bash/zsh/ksh/dash.
The only dependance is having curl.

Asking the password on the command line is something tricky, I'm not really at ease with such thing but I don't see any better option.

More than happy to get any feedback !

[h44z]

@Azylog looks promising =)

I think adding --overwrite parameter instead of the environment variable OVERWRITE will improve usability.

[h44z]

Closing this now, the API seems to work.