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
When using the API to create new Aliases (to automatically add/remove Kubernetes Pods with sip-ports in the alias table), I discovered that you cannot from the GUI create an AuthToken that has admin privileges to do so.
When an AuthToken is created, it includes a dummy user object which is used in place of a real user object for API access. This user object is always the AgentObjectforAuthToken defined in the schema as:
.. which seems a bit hack-ish. Especially since the usergroup is fixed to user and the only way to change it was to go and manually UPDATE the whole JSON in the DB.
Two proposals:
patch it, allowing setting of usergroup (and editing?) in the included dummy user object (and change all the "Tester" stuff to "API" ..); OR
rewrite it, allowing creation of API-only users (can't login) and instead of embedding the user object into the AuthToken just have the token point to the real API-only user.
Of course I would prefer option 2 as it would also allow setting of any user properties with the normal editor and not having to special-case every attribute that needs changing.
The text was updated successfully, but these errors were encountered:
I think the first way is more flexible, but more dangerous from security view. Another proposal, can we put this like a settings to the homer-app application and replace it ? Similar like: "token-user", "token-group", or just add the full object inside ?
When using the API to create new Aliases (to automatically add/remove Kubernetes Pods with sip-ports in the alias table), I discovered that you cannot from the GUI create an AuthToken that has admin privileges to do so.
When an AuthToken is created, it includes a dummy user object which is used in place of a real user object for API access. This user object is always the
AgentObjectforAuthToken
defined in the schema as:.. which seems a bit hack-ish. Especially since the usergroup is fixed to
user
and the only way to change it was to go and manually UPDATE the whole JSON in the DB.Two proposals:
Of course I would prefer option 2 as it would also allow setting of any user properties with the normal editor and not having to special-case every attribute that needs changing.
The text was updated successfully, but these errors were encountered: