Unexpected REST API paths change in 1.32.4465.96

Pritunl Pritunl VPN
1

We’ve recently upgraded from 1.32.4400.99 to 1.34.4681.89,
and noticed that this broke /key/<org_id>/<user_id> API,
which started to return 404.

Apparently, it’s the following commit that landed in 1.32.4465.96 that moved some of the /key/... API endpoints to /data/...:

-@app.app.route('/key/<org_id>/<user_id>', methods=['GET'])
+@app.app.route('/data/<org_id>/<user_id>', methods=['GET'])
 @auth.session_auth
 def user_key_link_get(org_id, user_id):

Is there a reason for this change?
Is it possible to change it back or provide an alias for backwards compatibility?

In general, what are the expectations with regards to Pritunl REST API stability and backwards compatibility?

2

This was done to add the external web process NaCl token request validation in Pritunl v1.32.4512.98. This adds an additional NaCl based cookie that allows the external pritunl-web process to validate a request before forwarding it to the root pritunl process where it then passes the standard session validation. Although this feature is less isolated when an API key is configured as the API keys can only be validate in the root process. This mode is indicated by web_auth_strict=false in the startup log message, it will still use the validation but the request will reach the root process where it will enforce the NaCl token check only for non-API key requests.

The problem was the other /key handlers are open for the client connection authentication and that one handler was an admin session so it needed to be seperated from the other /key handlers. This is visible in the pritunl-web/handlers/handlers.go. This has been the only breaking change to the API it’s unlikely other changes will be made.