fix: Hiding widgets / links from unauthorized users on welcome screen.

[TommyJackson85]

Related Issue

Closes #1074

Your solution

Attempting to hide welcomeScreenWidgets from unauthorised users, as they should not have access to if they're not authorised to use them.
Using app-form-builder as a first attempt.

My initial attempt was to do it from each welcomeScreenWidget but I only could manage to hide the link button. Here is what it looked like:

So I then applied SecureView to each mapped out Widget plugin from app-plugin-admin-welcome-screen/src/components/Welcome.tsx file, while passing in a scopes key from the app-form-builder welcomeScreenWidget plugin.
From both unauthorized and authorized accounts, here are the results as it appears to work:

@EmilK15 what do you think? Should I keep the Secure View from the Welcome.tsx file instead and just pass in Secure View scopes from welcomeScreenWidget? I am still yet to do this to other widgets. Just doing one as a first attempt.

How Has This Been Tested?

I am testing visually and manually through both authorized and unauthorized accounts

[TommyJackson85]

@EmilK15 I updated my initial post to try something different. :)

[Pavel910]

@TommyJackson85 this approach with defining scopes in the widget plugin is ok. Let's go that way. The only thing to remove is that SecureView from each plugin itself.

Another approach to the whole problem would be to convert widget on each plugin into a function, which would receive a Widget component, and then you'd only need to render it. That way the control would be in each individual plugin.

Hard to tell which one is better at this point.

[Pavel910]

I think this is an acceptable approach 👍

[Pavel910]

You can safely remove this SecureView.

[Pavel910]

This looks good to me. Let's go with this approach.

[TommyJackson85]

Yeah for sure, I was considering considering converting it to a function but it could of been set as an Object for a reason. each object is mapped out as jsx using map from Welcome.tsx. I agree with you on removing SecureView on each Widget too. I had no plans to keep applying SecureView to the buttons just the widgets. Just left it there to show what I tried. Better to just pass each scopes from them instead. I will work on it later.

…

Sent from my iPhone

[TommyJackson85]

@Pavel910 @EmilK15 I removed the unnecessary SecureViews from the widget and added the remaining scopes key values to the other displayed widgets. Now on unauthorised user accounts it looks like this:

For user accounts who have no permissions set, this above message should be removed or edited to something more welcoming and applicable because right now they don't have any actions to perform so it's misleading.
Maybe it should be for a new issue though.

On a side note, do you know where else in the project to test the code? Like automated tests? If they exist I could see if it covers the code I wrote.

[adrians5j]

@TommyJackson85, for Cypress tests, please check the https://github.com/webiny/webiny-js/blob/master/docs/CONTRIBUTING.md#cypress-tests.

Let us know if you'll have additional questions.

[Pavel910]

@TommyJackson85 regarding an empty Welcome screen - let's do it this way: when you get all plugins, you have an array of scopes required by each particular widget. If the user doesn't have access to any of the widgets, we can print a message to contact the administrator. I think this will be enough for now.

You can check plugin scopes programmatically, by using import { hasScopes } from "@webiny/app-security"; and render the message accordingly.

I really like how you try to handle all the different edge cases 🚀 🍻 👏

[TommyJackson85]

@TommyJackson85 regarding an empty Welcome screen - let's do it this way: when you get all plugins, you have an array of scopes required by each particular widget. If the user doesn't have access to any of the widgets, we can print a message to contact the administrator. I think this will be enough for now.

You can check plugin scopes programmatically, by using import { hasScopes } from "@webiny/app-security"; and render the message accordingly.

I really like how you try to handle all the different edge cases 🚀 🍻 👏

@Pavel910 I think i managed to use hasScopes correctly. :) Can you double check my recent commit? It displays a different message for users with no authorization. I manually tested it and it seems to work.

@doitadrian thanks! :) Will check it over the week and I will follow up with some questions if I need.

[TommyJackson85]

@Pavel910 my apologies, I didn't use hasScopes correctly and received this error:
##[error]@webiny/app-plugin-admin-welcome-screen: src/components/Welcome.tsx(111,46): error TS2345: Argument of type 'AdminWelcomeScreenWidgetPlugin[]' is not assignable to parameter of type 'ResourcesType'.

Let me try again. Any advice would be great.

[Pavel910]

Hey @TommyJackson85, sorry for the delay. This is what I think will solve the problem:

    // Check if user has access to at least 1 widget
    const canSeeAnything = getPlugins<AdminWelcomeScreenWidgetPlugin>(
        "admin-welcome-screen-widget"
    ).some(pl => hasScopes(pl.scopes, { forceBoolean: true }));

We need to see if a user can see at least 1 of the widgets. Each Widget plugin has scopes in form of an array. Array.some will tell us if at least 1 element passes the test. And hasScopes will process an array of scopes defined in the widget plugin, and tell you whether the user has all of the required scopes. It works in the AND manner, meaning that the user must have ALL requested scopes for hasScopes to return true.

Let me know if this helps!

[TommyJackson85]

i thaught it would be fixed as all checks have passed but i am getting this error or running the app locally. The Webiny loading icon appears then this error appears:

I didn't make any changes to that security file. Could my AWS IAM user be outdated or maybe its Mongodb related? Maybe check on your end if its working.

[Pavel910]

@TommyJackson85 this line here is causing your React error. You're trying to render an array of objects. Not sure what you wanted to render here, but this is the place to fix.

[TommyJackson85]

Oh I see. I was only doing that to test to see what it prints. I will delete now.

[TommyJackson85]

How do I grant permission for a user to use each widget? ( i.e. from an administrative account I want to grant an unauthorized account permissions for each widget access). This is just so I can do further manual testing on an account to get authorization for one or two widgets.

So far from and administrator account, I can only give a user these permissions:

[Pavel910]

@TommyJackson85 roles contain scopes. So you need to create a Role (or several of them) with a specific set of scopes. This way we allow administrators to structure their permissions however they like, and we only care the scopes at the code level.

[TommyJackson85]

@Pavel910 I think I managed to grant permissions for page building, but they only seem to appear in the side nav bar :(

As you can see, there is no page builder widget on the main page.
I added these scopes to try and create permissions (from an administrator account):

Is there anything I am missing?

[Pavel910]

@TommyJackson85 that's because the scope in widget plugins are not really related to what you have assigned to the user. In the Page Builder widget you have scopes: ["pb:settings"], should be pb:page:crud, and so on for all the plugins.

[TommyJackson85]

That is fair enough. So 'pb:settings' has nothing to do with the widget plugins? I will set all scopes to page:crud related scopes instead so.

[TommyJackson85]

@Pavel910 would I be better to apply all potential scope types to the the scopes array including both pb:settings and pb:page:crud for example?

[Pavel910]

@TommyJackson85 I think pb:page:crud makes the most sense, because the widget is linking to Pages List, which is a module for creating pages. pb:settings is not relevant here. Also since hasScopes works in an AND fashion, you need to be careful not to include scopes that may not be present in user's token.

[TommyJackson85]

Ok so I will just use page:crud scopes for now so. thanks for the advice!

[TommyJackson85]

@Pavel910
These are the scopes I found, as you see there is nothing for CMS

I found these via Security Roles -> Security - Users.

[Pavel910]

@TommyJackson85 CMS scopes are in progress in another PR: #1088.
You can safely ignore that one for now, simply set the scopes to [] to let that widget always be visible, and we'll come back to it later.

[TommyJackson85]

Ok, no problem! If we successfully merge this I can let me know about the scope array from the welcomeScreenWidget file.

[TommyJackson85]

pb:page:crud and forms:form:crud are now the scopes being used for their respective plugins and they appear to work as I've tested them manually. CMS Widgets remains accessable for all as its scopes are empty.
Are you happy to merge this PR?

Just for further context, from the side nav related pull request, "settings" scopes were being used for page builder, form builder and headless cms tabs under settings in the side nav. It might be worth retesting them. Should the crud scopes be applied to them too?

[Pavel910]

@TommyJackson85 Great! I think this is good for merging, and no you don’t need to add crud scopes to settings navigation items. Settings scopes are for settings, crud scopes are for crud modules. So it’s all good now. We’ll do further refinement later on, when the need arises.

I’ll merge this for the next release, feel free to change the draft status of PR and please update the PR body to remove the temporary text.

Thanks and good work! :)