-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR #7137 introduced a breaking change into path-scopes matching #7173
Comments
@PalSzoboszlay Thanks for documenting this. I will be investigating for either a bugfix or a documentation update, and will post updates here. Thanks |
Seems similar to what I encountered and posted in discussion #7163 |
I have the same issue with localhost! |
Adding a comment to keep this issue open |
@jo-arroyo This issue was closed automatically, can I expect an update for it anyways? |
Reopening issue. As the change made to the MSAL Interceptor was to address a bug in the way MSAL Interceptor handled relative paths (as you linked above), I will update the documentation to reflect this. Apologies for the confusion. I will keep this issue open and update it when that change is made. |
Core Library
MSAL.js (@azure/msal-browser)
Core Library Version
3.17.0
Wrapper Library
MSAL Angular (@azure/msal-angular)
Wrapper Library Version
3.0.20
Public or Confidential Client?
Public
Description
Bug source:
microsoft-authentication-library-for-js/lib/msal-angular/src/msal.interceptor.ts
Line 286 in 362442e
checkUrlComponents's new implementation has a way stricter path matching than previously, so
Given a protected resource map of "myApi.companyName" - scopes
and a GET request going out to "https://myApi.companyName.com/route"
(using MsalInterceptor)
while running the UI locally (http://localhost:4200)
The method already returns false when checking the protocol because it tries to match "http" to "https", but it would also fail the next host match ("localhost:4200" vs "myApi.companyName.com").
In matchResourcesToEndpoint, the absolute key from "myApi.companyName" turns into "http://localhost:4200/myApi.companyName", with the keyComponents.pathname being "/myApi.companyName", and this would be compared to the absoluteEndpoint's pathname "/route" which wouldn't match either.
Previously it had no issue matching "myApi.companyName" to "https://myApi.companyName.com/route" to get a token, but now it logs "Interceptor - no scopes for endpoint" with verbose logging
(The issue would be the same if it wasn't running locally, as the deployed UI's host is not "myApi.companyName.com")
Error Message
No response
MSAL Logs
(app) MSAL Logging: [Mon, 24 Jun 2024 10:59:53 GMT] : [eef18fce-9344-4da7-ad45-8436b465b901] : @azure/msal-angular@3.0.20 : Verbose - MSAL Interceptor activated
auth.module.ts:41 (app) MSAL Logging: [Mon, 24 Jun 2024 10:59:53 GMT] : [eef18fce-9344-4da7-ad45-8436b465b901] : @azure/msal-angular@3.0.20 : Verbose - Interceptor - getting scopes for endpoint
auth.module.ts:41 (app) MSAL Logging: [Mon, 24 Jun 2024 10:59:53 GMT] : [eef18fce-9344-4da7-ad45-8436b465b901] : @azure/msal-angular@3.0.20 : Verbose - Interceptor - no scopes for endpoint
Network Trace (Preferrably Fiddler)
MSAL Configuration
Relevant Code Snippets
Reproduction Steps
Expected Behavior
The Bearer token should be added to the request instead of logging "no scopes for endpoint". Alternatively please update your documentation to explain how the protectedResourceMap should be set up in the future that doesn't require something like the following hack: #7111 (comment)
Identity Provider
Entra ID (formerly Azure AD) / MSA
Browsers Affected (Select all that apply)
Chrome, Firefox, Edge
Regression
@azure/msal-browser@^3.15.0 @azure/msal-angular@3.0.18
Source
Internal (Microsoft)
The text was updated successfully, but these errors were encountered: