It looks like the $Role variable only works with a single page. The $Role variable is empty when you have multiple pages.
New-UDDashboard -Title 'Dashboard' -Pages @($Page1, $Page2)
I’m also seeing this, I noticed that the $pages variable is also blank
Hmmm weird. The $Roles variable should be populated for every execution. I will take a look. As for the pages, I wasn’t aware that was missing but I can take a look at that too.
Ignore me on the $pages variable, its populated. Its just the way I was accessing it, seems theres a difference in behaviour from the UD 2.9 admin console to the Universal Dashboard console.
For example if you type get-variable in 2.9 admin console you get output, in universal you dont.
Did the HasClaim method ever get put in so we can just copy/paste our old methods instead of remaking them?
I am still getting errors when i try to use
New-UDPage -AuthorizationPolicy
[09-15-20 11:05:38 AM] Startup: A parameter cannot be found that matches parameter name 'AuthorizationPolicy'.
New-UDPage -AuthorizedRole
[09-15-20 11:05:38 AM] Startup: A parameter cannot be found that matches parameter name 'AuthorizedRole'.
Have these been added yet? This is really something holding me back from being able to progress with building using the newer versions.
Using 3.0.2 UD Framework
For all universal UD frameworks I believe you have to use roles now:
and
https://docs.ironmansoftware.com/dashboard/dashboards/migrating-from-universal-dashboard-2.9#authentication-and-authorization
Yes, but that is for changing content on the page, i would rather just remove access to the page entirely.
@adam, Is page based security entirely going away? The blog and docs show editing the content of the page but it seems like a lot of extra work as opposed to keeping the Authorization on the page itself like it was in 2.9 and older.
We are adding dashboard-based authorization in 1.4. You’ll be able to assign a role to the dashboard itself rather than on a page by page basis. This will require less coding on your part (e.g. checking the $roles) variable but won’t be under a single dashboard.
We’re still looking at implementing page-based roles but we’re not there yet.
Thanks for the update Adam. I do get what you mean jacob.
I think this would be a big one for me too, while I was considering writing a function to add into the top of every page with the app bar, nav menu, and access denied message based on roles, I don’t want to reinvent the wheel if a better way to do it is going to be implemented. I’ll probably just look at converting everything else and getting all my pages ready and working for now on V3 until this comes along and then I can deploy it over my production V2 instance once it becomes a feature.
Yeah, I can’t put UD3/PSU into production without page based authorization. Having dashboard based is nice, but it still not even close to matching the functionality of UD2.9. With my current setup, I would need to run about 8 different dashboards and I can’t even share a cache between them because they are separate instances.
I feel like the entire move to PSU was rushed and there is so much functionality that was lost and still hasn’t come back even months later. and it doesn’t look like it is going to come back to have the same level that 2.9 had for a while.
I already have to re-write most of my dashboard to work in 3.0 as a result of all the changes and cmdlets that were dropped. I have no motivation to even do that much when I can’t implement a similar level of security that we are used to.
Ok. I feel you. This should have been implemented in the beginning. I’ve implemented page-based authorization for PSU 1.4 and UDv3.1. Some recent changes to the internals made this much easier than I would have thought. This will be in tonight’s nightly build as well.
https://docs.ironmansoftware.com/dashboard/components/pages#role-based-access
3 Likes
I will give this a go as soon as I can!
I think that with V3 its a big overhaul so there’s always going to be a barrier there for people wanting to migrate, people need to adapt or recreate what they have already, but in the long run even if that takes time its going to be beneficial.
Not having the roles param on pages wasn’t a show stopper for me as you could still just put a
if($roles -notcontains "administrator){<access denied msg> ; return/break}
sort of code in the top of your pages, it’s just a different way of doing it to specifying a param on new-udpage itself. Although now it’s going to be much easier and cleaner to implement.
I think that the move to universal was always going to be a tricky one for a lot of people especially if they’ve done a ton of customisations like me. UD 2.9.0 to 2.9.1+ had some considerable changes, so making the transition smoother with like for like or where possible similar functionality is always going to help drive more people to make the jump so this will really benefit I’m sure.
I think once people have moved from UD 2.9.0 to 2.9.1+ and they’re actively using universal, it will also make it easier for them to jump from there to V3 whether thats starting fresh or migrating.
Either way, really appreciate you putting in the extra work to make this change. 