SPFx CDN URLs not consistently added to Trusted Script Sources (CSP)
Hi everyone, We’re currently investigating an issue related to SharePoint Online Content Security Policy (CSP) and Trusted Script Sources (TSS) for SPFx solutions. [SharePoint Online] [SPFx] [CSP] Scenario We deployed multiple SPFx .sppkg packages via App Catalog These solutions load scripts from an external CDN (cdnBasePath, with includeClientSideAssets: false) Expected Behavior As per documentation, CDN URLs used by SPFx solutions should be available/registered in Trusted Script Sources so that scripts can load under CSP enforcement Observed Behavior Only some CDN URLs (from certain packages) appear in Trusted Script Sources Others are missing, even though they are similarly configured and deployed Due to this, scripts from those missing sources are blocked by CSP, and the extension fails to load Additional Notes No use of eval() or inline scripts in our code Re-deploying packages sometimes resolves the issue (CDN URLs get registered afterward) Behavior appears inconsistent across environments Question Has anyone encountered a similar issue where: Trusted Script Sources were partially auto-populated from App Catalog deployments? CDN URLs from some SPFx packages were not registered automatically? Any insights on: Root cause Known limitations Best practices to ensure consistent registration would be really helpful. Thanks in advance!
Is Creating Multiple ClientContext Instances Efficient in CSOM for one Site Url?
Is it efficient to create a new ClientContext for each site URL and for each query, such as getting site users, lists, groups, and group members from the Web object? These queries can return a very large number of items, and CSOM does not support paging when retrieving data from Web properties. Because of this, there is a risk of memory issues. In this case, is creating multiple ClientContext objects a good approach? Also, how does ClientContext work internally, and how does it handle memory and performance?
any possible to extend client ID and secret for app registered in SharePoint Online
Hi Team, is there any possible to extend client ID and secret for app registered in SharePoint Online? right now, we are not allowed to create any new app registration from SharePoint Online, only way is from Azure AD - App registration. how about the client ID and secret getting expired which is created earlier using SharePoint Online? is there any way like powershell script something to extend the validity of Client ID and secret for app registered in SharePoint Online? if yes, please share the detailed instructions and guidelines to perform. if no, then what is the possible way for next step of actions to do? you can reachout to me - mailto:email address removed for privacy reasons for further discussion about this issue. Thanks for the help!
SPFX 1.21.1 in monorepo - utility module could not be exported
I am trying to migrate multiple projects to monorepo. I need to migrate some common utilities functions in a common module. There is an export warning that the module has no exports, while it does has. Running npm run spfx1:build works fine. But when I do npm run spfx1:serve it throws a warning export 'DemoUtilities' (imported as 'DemoUtilities') was not found in 'utilities-library/utils' (module has no exports) Opening the a SharePoint page online, it errors with missing exports. Can you point me to possible solutions? Here is a very simple OOB SPFX solution structure: utilities-library - src -- utils.ts - index.ts - package.json - tsconfig.json spfx1 - config - sharepoint - src -- skipped for brevity - gulpfile.js - package.json - tsconfig.json package.json tsconfig.base.json Specifics for per files utilities-library -> package.json { "name": "utilities-library", "version": "1.0.0", "main": "lib/index.js", "types": "lib/index.d.ts", "scripts": { "start": "node index.js", "test": "echo \"test\"" }, "type": "module", "workspaces": [ "true" ], "devDependencies": { "typescript": "^5.3.5" } } utilities-library ->tsconfig.json { "compilerOptions": { "composite": true, "declaration": true, "outDir": "lib" }, "include": ["**/*.ts"] } utilities-library ->index.ts export { DemoUtilites } from './src/utils'; utilities-library -> utils.ts import { ISPFXContext, spfi, SPFx } from "@pnp/sp"; import "@pnp/sp/webs"; import "@pnp/sp/lists"; export const DemoUtilites = { checkListExists: async ( listTitle: string, context: ISPFXContext ): Promise<boolean> => { const sp = spfi().using(SPFx(context)); return new Promise<boolean>((resolve) => { sp.web.lists .getByTitle(listTitle)() .then(() => { resolve(true); }) .catch((error) => { if (!(error?.status === 404)) { console.log(`Error checking list ${listTitle}`, error); } resolve(false); }); }); } } spfx1 -> gulpfile.js 'use strict'; const build = require('@microsoft/sp-build-web'); const path = require("path"); build.addSuppression(`Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.`); build.configureWebpack.mergeConfig({ additionalConfiguration: (generatedConfig) => { generatedConfig.resolve = generatedConfig.resolve || {}; generatedConfig.resolve.alias = { ...(generatedConfig.resolve.alias || {}), 'utilities-library': path.resolve(__dirname, '../utilities-library/lib'), 'utilities-library/utils': path.resolve(__dirname, '../utilities-library/lib/utils') }; return generatedConfig; } }); var getTasks = build.rig.getTasks; build.rig.getTasks = function () { var result = getTasks.call(build.rig); result.set('serve', result.get('serve-deprecated')); return result; }; build.initialize(require('gulp')); spfx1 -> package.json { ... "dependencies": { "@microsoft/decorators": "1.21.1", "@microsoft/sp-core-library": "1.21.1", "@microsoft/sp-dialog": "1.21.1", "@microsoft/sp-listview-extensibility": "1.21.1", "@pnp/sp": "^4.12.0", "utilities-library": "^1.0.0", "office-ui-fabric-react": "^7.204.1", "react": "17.0.1", "react-dom": "17.0.1", "tslib": "2.3.1" }, ... } spfx1 -> tsconfig.json { "extends": "../tsconfig.base.json", "compilerOptions": { "rootDir": "src", "outDir": "lib" }, "include": ["src/**/*.ts", "src/**/*.tsx"], "references": [ { "path": "../utilities-library" } ] } root -> package.json { "name": "monorepo-test", "workspaces": [ "spfx1", "utilities-library" ], "scripts": { "spfx1:build": "gulp build -f ./spfx1/gulpfile.js --workspace spfx1", "spfx1:clean": "gulp clean -f ./spfx1/gulpfile.js --workspace spfx1", "spfx1:serve": "gulp serve -f ./spfx1/gulpfile.js --workspace spfx1 --nobrowser", "spfx1:bundle": "gulp bundle -f ./spfx1/gulpfile.js --workspace spfx1", "spfx1:pkg": "gulp package-solution -f ./spfx1/gulpfile.js --workspace spfx1", "spfx1:prod": "gulp build -f ./spfx1/gulpfile.js --workspace spfx1 --ship & gulp bundle -f ./spfx1/gulpfile.js --workspace spfx1 --ship & gulp package-solution -f ./spfx1/gulpfile.js --workspace spfx1 --ship", "utilities-library:build": "tsc --project utilities-library/tsconfig.json", "utilities-library:watch": "npm run utilities-library:build -- --watch", "clean:node": "rm -rf **/node_modules" }, "devDependencies": { "npm-run-all": "^4.1.5" } } root -> tsconfig.base.json { "extends": "./node_modules/@microsoft/rush-stack-compiler-5.3/includes/tsconfig-web.json", "compilerOptions": { "target": "es5", "forceConsistentCasingInFileNames": true, "module": "esnext", "moduleResolution": "node", "jsx": "react", "declaration": true, "sourceMap": true, "experimentalDecorators": true, "skipLibCheck": true, "outDir": "lib", "inlineSources": false, "noImplicitAny": true, "rootDir": ".", "baseUrl": ".", // Important for path mapping "paths": { "utilities-library/*": [ "utilities-library/lib/*" ] }, "typeRoots": [ "./node_modules/@types", "./node_modules/@microsoft" ], "types": [ "webpack-env" ], "lib": [ "es5", "dom", "es2015.collection", "es2015.promise" ] }, "include": [ "src/**/*.ts", "src/**/*.tsx" ] }
401 unauthorised for ExecuteQuery in sharepoint CSOM
Hi, I am trying to connect the sharepoint site with client id and secret but getting 401 unauthroised error while hitting the executequery() method. While doing app registrations both Microsoft graph and share point API permissions with full site control has been given including trusted the app through appinv.aspx. Still getting 401 unauthorised error. Since ACS is retiring, do we need to follow any other permissions for share point level site access. The same execute query is working fine for client id, certificate combination. But not working for client id and secret. static void Main(string[] args) { var authManager = new AuthenticationManager("***************************", "C:\\Program Files\\OpenSSL-Win64\\bin\\certificate.pfx", "*******", "********.onmicrosoft.com"); using (var cc = authManager.GetContext("https://****.sharepoint.com/sites/****")) { cc.Load(cc.Web, p => p.Title); cc.ExecuteQuery(); Console.WriteLine(cc.Web.Title); ListCollection listCollection = cc.Web.Lists; cc.ExecuteQuery(); // this is working fine }; // Replace with your SharePoint Online details string siteUrl = "****************************"; string tenantId = "***************************"; string clientId = "********************************"; string clientSecret = "******************************"; // App secret try { using (var context = GetClientContextWithOAuth(siteUrl, tenantId, clientId, clientSecret)) { // Example: Retrieve web title Web web = context.Web; context.Load(web, w => w.Title); context.ExecuteQuery(); // this is throwing 401 unauthorized error Console.WriteLine("Connected to: " + web.Title); } } catch (Exception ex) { Console.WriteLine("Error: " + ex.Message); } } private static ClientContext GetClientContextWithOAuth(string siteUrl, string tenantId, string clientId, string clientSecret) { // Azure AD OAuth 2.0 endpoint string authority = $"https://login.microsoftonline.com/*******************"; // Use MSAL to acquire an access token var app = ConfidentialClientApplicationBuilder.Create(clientId) .WithClientSecret(clientSecret) .WithAuthority(new Uri(authority)) .Build(); var authResult = app.AcquireTokenForClient(new[] { $"{siteUrl}/.default" }).ExecuteAsync().Result; if (authResult == null) { throw new Exception("Failed to acquire the access token."); } // Use the access token to authenticate the ClientContext var context = new ClientContext(siteUrl); context.ExecutingWebRequest += (sender, e) => { e.WebRequestExecutor.WebRequest.Headers["Authorization"] = "Bearer " + authResult.AccessToken; }; return context; }
How to Get the Correct Client ID for Graph API Authentication in SPFx Without Forcing Login?
Hello everyone, I'm trying to connect my SPFx web part to the Microsoft Graph API in the most modern and seamless way possible, avoiding any additional login prompts for the user. Here's the setup I'm currently using: _graph = graphfi().using(graphSPFx(context as ISPFXContext)); It's crucial for me to retrieve all the Graph API credentials directly from the SharePoint context to ensure a seamless experience for users. However, I'm encountering a 400 error when trying to acquire the token: AADSTS500011: The resource principal named 806f609a-6160-4235-ab06-91c8fe86ccee was not found in the tenant named ***. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant... The issue here is that the clientId mentioned (806f609a-6160-4235-ab06-91c8fe86ccee) does not exist in our tenant's Azure AD, and it never has. From my research, this seems like some kind of fallback client ID from Microsoft. The only way I can get it to work is by explicitly adding the correct clientId manually like this: _graph = graphfi().using(graphSPFx(context as ISPFXContext)).using(MSAL({ authParams: { scopes: [...] }, configuration: { auth: { clientId: "CORRECT_CLIENT_ID", // copied from AD authority: "https://login.microsoftonline.com/{tenantId}" }, cache: {...} } })); However, this approach causes a redirect or popup prompt, often requiring users to use multi-factor authentication on their mobile devices. My goal is to avoid this entirely. Questions: How can I retrieve the correct clientId directly from the SharePoint context? The context itself doesn't seem to expose what client ID is being used to authenticate to the Graph API. Is there any way to handle this without modifying the context or forcing a re-login? Why does SharePoint seem to be using this "mysterious" fallback client ID that doesn't exist in the tenant? I've looked at multiple tutorials, but most of them are outdated by several years (some over 8 years old). Even following those tutorials results in the same error when testing in the Workbench or after deployment. Does anyone know a way to address this issue without combing through outdated documentation? I’d appreciate any guidance or insights! Thank you in advance! Best regards, Mario
