A few questions / suggestions
Posted: Mon Mar 02, 2020 8:37 pm
I have a number of suggested improvements / questions.
1) Is there anyway to "hook" into the user / pass validation process server side? In order to start a remote app, the details of the remote app and user / password are passed as url parameters. I would prefer to pass in a token or use an existing authentication header token and from that token determine the Windows user.
In my use case, users log in to a website using their credentials which do not match the Windows users credentials. To avoid exposing the Windows credentials, if I were able to "hook" into the user validation process (server side) then I could use the token provided as a url parameter or the authentication header to return a valid login. This would allow me to keep the Windows credentials secret from prying eyes (browser development tools).
2) If a remote app is started by passing the necessary url parameters but the credentials are wrong, the user is then presented with the Windows login screen. Ideally the user would never be presented with the Windows login screen for remote apps.
3) When starting a remote app, the animated gif is displayed for a predetermined, configurable duration. The user will see the Windows login screen if the remote session hasn't completely started within the configured amount of time. Since a connection has already been established via websockets, could this be changed so that the process that starts the remote session sends a notification to the browser once the session is fully up and available (including the remote app)? The animated gif could then be hidden when the notification is received. This way the animated gif is displayed for only as long as is needed - could maybe include a maximum amount of time that a session should take to start before aborting.
4) Webcredentials.ini is stored in clear text. This file includes the passwords for the mapped Windows user. Ideally this file would be encrypted and an api made available for end users so that the list of webusers can be maintained outside of the admin tool. Preference would be that the encryption is not machine specific so that the file could be easily copied between servers if need be.
5) Could the webcredentials.ini location and filename be configurable? This would give admins the ability to maintain one copy of the file and share it between multiple servers.
Thanks.
1) Is there anyway to "hook" into the user / pass validation process server side? In order to start a remote app, the details of the remote app and user / password are passed as url parameters. I would prefer to pass in a token or use an existing authentication header token and from that token determine the Windows user.
In my use case, users log in to a website using their credentials which do not match the Windows users credentials. To avoid exposing the Windows credentials, if I were able to "hook" into the user validation process (server side) then I could use the token provided as a url parameter or the authentication header to return a valid login. This would allow me to keep the Windows credentials secret from prying eyes (browser development tools).
2) If a remote app is started by passing the necessary url parameters but the credentials are wrong, the user is then presented with the Windows login screen. Ideally the user would never be presented with the Windows login screen for remote apps.
3) When starting a remote app, the animated gif is displayed for a predetermined, configurable duration. The user will see the Windows login screen if the remote session hasn't completely started within the configured amount of time. Since a connection has already been established via websockets, could this be changed so that the process that starts the remote session sends a notification to the browser once the session is fully up and available (including the remote app)? The animated gif could then be hidden when the notification is received. This way the animated gif is displayed for only as long as is needed - could maybe include a maximum amount of time that a session should take to start before aborting.
4) Webcredentials.ini is stored in clear text. This file includes the passwords for the mapped Windows user. Ideally this file would be encrypted and an api made available for end users so that the list of webusers can be maintained outside of the admin tool. Preference would be that the encryption is not machine specific so that the file could be easily copied between servers if need be.
5) Could the webcredentials.ini location and filename be configurable? This would give admins the ability to maintain one copy of the file and share it between multiple servers.
Thanks.