You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if it were possible to hide the Shlink API key (and to be honest the entire "Manage Servers" screen and functionality in certain circumstances
The use case is this: We are running Shlink and the Shlink Web Client as Azure App Services. For the Web Client, we are authenticating users via AAD through built-in functionality in the Azure App Service itself (it won't pass requests to the app through the reverse proxy until the user is authenticated via Azure AD)
We then are providing the Shlink server config including API to the Web Client via environment variables so it's pre-configured
What we'd like to do is open this service up to a wider audience in our company, but the API key would leak out as users could find it in the Web Client by going to the Manage Servers section
Since the server config is pre-defined, and we don't want them using any other Shlink servers anyway, all we need to do is hide all UI references to the API and the manage users screen
I understand that if you really wanted to you could dig into the app through dev tools and find the key. Given this would still be a small group of trusted users, and mostly users in the marketing department, that is less of a threat than having the API key directly exposed in UI (although if there was a way to obsfucate or encrypt the API key even from digging in dev tools, that would be great too)
The text was updated successfully, but these errors were encountered:
although if there was a way to obfuscate or encrypt the API key even from digging in dev tools, that would be great too
Unfortunately, since this app is fully run on the browser, there's no way to safely store the value in a way that the app itself can read it but it's not accessible to users.
One thing I've wanted to do for a long time is a new generation Shlink dashboard, with its own backend, user management and permissions, configuration properly stored in a database, and secrets kept safe and never leaked to the browser.
Eventually, it could even support Single Sign-on, although, this would come later.
The problem is that it requires quite some work, and I've always deprioritized it in favor of smaller improvements which would bring more value earlier. But the plan is to get it eventually done.
It would be great if it were possible to hide the Shlink API key (and to be honest the entire "Manage Servers" screen and functionality in certain circumstances
That said, I get your use case, and it's quite cool you got to add a layer of authentication using Azure AD.
Perhaps I could add some way to provide extra config to the client, in a similar way servers are pre-configured.
This should later fit nicely on how the dashboard could potentially pass permissions down to the client, to determine which sections can be displayed.
But again, this is just a UI improvement for controlled environments like the one you described. It would not prevent anyone from manually editing servers or getting API keys directly from the browser's local storage.
Summary
It would be great if it were possible to hide the Shlink API key (and to be honest the entire "Manage Servers" screen and functionality in certain circumstances
The use case is this: We are running Shlink and the Shlink Web Client as Azure App Services. For the Web Client, we are authenticating users via AAD through built-in functionality in the Azure App Service itself (it won't pass requests to the app through the reverse proxy until the user is authenticated via Azure AD)
We then are providing the Shlink server config including API to the Web Client via environment variables so it's pre-configured
What we'd like to do is open this service up to a wider audience in our company, but the API key would leak out as users could find it in the Web Client by going to the Manage Servers section
Since the server config is pre-defined, and we don't want them using any other Shlink servers anyway, all we need to do is hide all UI references to the API and the manage users screen
I understand that if you really wanted to you could dig into the app through dev tools and find the key. Given this would still be a small group of trusted users, and mostly users in the marketing department, that is less of a threat than having the API key directly exposed in UI (although if there was a way to obsfucate or encrypt the API key even from digging in dev tools, that would be great too)
The text was updated successfully, but these errors were encountered: