SPFx as spyware - updates #1900
Conversation
|
These are great articles to educate the ecosystem - however - we seem to be missing the technical detail that to be able to install or start using SPFx solutions - they have to be deployed and installed by administrators. Would absolutely include that detail already to the part 1 to avoid confusion - as now it gives an impression that anyone can start using SPFx solutions - which of course it not the case... this was the key differentiator vs the script editor web part we had in the classic experience - where admin and governance for the extensibility was not required... with the SPFx - any solution which is installed on the tenant has to be explicitly approved by the tenant administrator - or the app administrator if responsibility is delegated forward - so there's additional governance and admin controls by design for the IT - which also can control the usage of the SPFx solutions from one central location. This quite important detail seems to be missing at least from the part 1 on this series. Worth noticing is also that the SPFx solutions have the central coordination and governance for the IT administrators - which is a bit different than the Power Platform side of the story. Both have advantages and disadvantages for sure. Power Platform improves all the time though for sure on these areas as well - which is great. As said - otherwise it's great that we educate the customers on the different considerations, but would love to get above details noted to avoid confusion. |
|
Thx @VesaJuvonen for the feedback. I will update the articles to elaborate more on roles and responsibilities. I see your point, it's at the very end and could be easily missed. thx again |
…lities of admins and site owners
|
@VesaJuvonen Please have a look. I think that these two articles in the series now paint a more complete picture :) Still waiting for the second PR:
Please do not approve before the pnp/sp-dev-fx-webparts#5203 is merged |
|
"With the site-level app catalog, however, once enabled, site owners can install the solutions themselves. " However - you need to be a tenant administrator to create site-level app catalog, providing IT full governance and control on allowing site owners to do this. There's no way end users can start using SPFx solutions without control and governance from the administrators. In general site-level app catalogs only have really minimal use currently worldwide for these exact reasons - as it would allow the site collection owners to accidently cause issues - after the usage has been allowed by the administrators. |
|
@VesaJuvonen Not sure what you'd like me to correct here. How about I quote you? This would be fantastic, to have your statement here. It is not my goal to claim that SPO securing is bad. It isn't. But after hearing things like:
I decided we really have to discuss this topic. It's not about vulnerabilities in SPFx, SPO or M365. We are the vulnerability |
|
Removed all the other changes from the PR to isolate the topic |
|
Thx @kkazala on the updates. This is incredibly important topic which has to be for sure discussed so that our customers and partners understand what they are consenting and what the solutions can do within their environment. Transparency is for sure the key and liked following callout a lot - "This approval process is far more than just a formality and must be taken extremely seriously. The decision to approve a solution can have significant implications for the security of the entire tenant." Edits are definitely great and provide more insights on the process - as initially the admin role was not discussed in the article - and it simply called out that solutions can access information - which is not wrong - but it can only happen if administrators approve the solutions. That's really the key on the modern SharePoint experiences - with SPFx vs the classic SharePoint with script editor web part - which technically allowed these kind of things to be done WITHOUT admin control - as any site owner could copy script and place that on the site. Since classic SharePoint is still supported (yes - amazing it still is) - we have introduced the default settings with the noscript setting - which by default blocks end users to use script editor web part in classic SharePoint. So - there's at least recommendations for this from Microsoft - even though some customers are still using classic and they allow script editor web part usage - which is a clear risk. On the PR - definitely ok to get merged - however it is now referencing the part 2 article - which was removed from this PR, so would not merge this yet... So - would suggest to get the part 2 back - or edit this to remove that link for now - and then submit a new PR when you are ready with that. Thank you for helping to increase the awareness of the security topics - critical for the ecosystem to understand 🙏 |
|
@VesaJuvonen Fantastic, I'm happy you like the updates :) Do you know how long it takes to approve webpart samples? thank you for all your help and support =) |
|
Just to follow up on here - you are not forgotten @kkazala. Your PR in the SPFx web parts should be processed this weekend and then we can merge these updates in early next week. Thanks for your patience. |
|
Awesome, thx @VesaJuvonen for the heads up. |
|
@VesaJuvonen I updated the links to the scripts and the webpart, so let's merge, if it's OK with you? |
|
@VesaJuvonen do you think we could merge it some time soon? :) |
Category
Contents of the Pull Request
Important This PR has a dependency on
Please do not approve before the above PR are merged
2nd article in SPFx as spyware series, covering
Reference added to the 1st article from the series
And... tags added to the old Power Platform extensibility articles. I already forgot about this change and as a result, everything in one PR. I'm sorry, can we leave it like that?
Spaces added automatically by "Prettier", hope it's ok?
Guidance