PowerShell Universal - 5.0.16

PowerShell Universal - 5.0.16

Release Notes

Admin Console

  • Renamed Functions tab in app editor to Module
  • Fixed an issue creating a CRON schedule on the script page (#4035)
  • Fixed an issue with the Run button on the health checks page (#4024)
  • Added Start Time, Created Time and Elapsed Time to the jobs table (#4028)
  • Fixed an issue where form authentication was shown on the login page when disabled (#4041)
  • Added reset branding button (#4030)
  • Fixed an issue where non-persistent cache data had missing time stamps
  • Added Available in Branch to UI
  • Improved memory usage output on process page (#3828)
  • Fixed an issue with the failed login configuration page
  • Added variable value form (#4049)
  • Fixed an issue where System would show in the permission identity selector (#4040)
  • Fixed an issue where Reader role could execute scripts in admin console (#4061)
  • Fixed an issue where the admin console could exhaust SQL connections (#4056)

APIs

  • Added -Computer to Send-PSUEvent (Invoke-PSUCommand)
  • Fixed an issue where variables were retained between invocations in a persistent runspace
  • Fixed an issue executing endpoints that use -Module-Command (#4053)

Apps

  • Added -Checkbox to New-UDSelect (#1996)
  • Fixed an issue with New-UDAutocomplete -Multiple layout (#3756)
  • Added -SortType numeric to New-UDTableColumn (#3837)
  • Fixed an issue with -Locale in New-UDDatePicker (#4017)
  • Fixed margin of UDTextbox with an icon (#4051)

Automation

  • Fixed an issue scheduling the groom job past 59 minute intervals (#4031)
  • Fixed an issue renaming schedules (#4034)

Module

  • Fixed an issue where module help was not updating properly.
  • Fixed an issue with Get-PSUCache -Key case sensitivity (#4043)

Portal

  • Links now open in a new tab (#4027)
  • Added disabled and roles settings for portal (#4037)
  • Fixed an issue with portal authentication redirects (#4010)

Platform

  • Fixed an issue grooming jobs when using PostgreSQL (#4032)
  • System log level can now be set in the admin console

Downloads

4 Likes

Wonderful!
A SAML2 Button on the login page.
And it does log me in, but loops endless.

What needs to be changed in the config?

I wanted to point out that there’s a noticeable increase in performance in this version. I assume it’s related to the change in log level writing. Regardless of why, I’m happy about it. Thanks!

1 Like

Same.

Also of note, the Logout button takes you to the /login page, which we have disabled from public access (via our load-balancer) due to there not being any way of turning off the local admin account entirely and there not being any way to restrict who can access the /login page within PSU, so with this behavior if I were to use the Logout button in our setup while accessing PSU publicly, it would result in a timeout due to the inability to reach the /login page from the internet. @adam, a better design may be to just take users to the base PSU path rather than taking them to /login, so it uses whatever the setup uses for the default login method.

1 Like

I opened an issue to track this. SAML2 Redirect Loop from Login Page · Issue #4075 · ironmansoftware/powershell-universal · GitHub

Redirecting to the login page, even when using SSO, was actually a feature request that needs a configuration option to allow users to hide\disable the page completely and just redirect to the desired resource. Having a login page allows the user to select their authentication method when multiple are defined.

That said, we need better logic. It shouldn’t redirect to the login page at all if only one auth method is defined and it’s SSO\external auth.

We have requests for multiple auth methods of the same type, etc and that complicates the story but not the case right now.

2 Likes

As in entirely separate SAML setups (i.e., Azure and Google at the same time), or as in multiple of the same “brand” (i.e., 2 separate Azure tenants at the same time)?

I don’t think it would matter in the end. You could just have multiple authentication methods of certain types or provider. For example, forms or client cert wouldn’t work this way.

You could have two azure tenants and configure two auth methods. They would need to be named, and we would need some mechanism for the user to select which to auth to.

It would also be possible to configure the preferred authentication and maybe even enforce certain auth for certain APIs or apps (also open feature requests).

2 Likes