Skip to content

Commit e69a2a9

Browse files
committed
minor refactor
1 parent 97b114b commit e69a2a9

File tree

2 files changed

+4
-3
lines changed

2 files changed

+4
-3
lines changed

5-AccessControl/2-call-api-groups/README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -539,7 +539,7 @@ public static async Task ProcessAnyGroupsOverage(TokenValidatedContext context)
539539

540540
#### Caching user group memberships in overage scenario
541541

542-
Since overaged tokens will not contain group membership IDs, yet these IDs are required for controlling access to pages and/or resources, applications have to call Microsoft Graph whenever a user action (e.g. accessing a page on the UI, accessing a todolist item in the web API etc.) takes place. These network calls are costly and will impact the application performance and user experience. As such, both the SPA and web API projects here would benefit from caching the group membership IDs once they are fetched from Microsoft Graph for the first time. By default, these are cached for 1 hour in the sample. Cached groups will miss any changes to a users group membership for this duration. If you need more fine grained control, you can configure cache duration in [auth-config.ts](./SPA/src/app/auth-config.ts) for the SPA and in [appsettings.json](./API/TodoListAPI/appsettings.json) for the web API. If your scenario requires capturing real-time changes to a user's group membership, consider implementing [Microsoft Graph change notifications](https://learn.microsoft.com/graph/api/resources/webhooks) instead.
542+
Since overaged tokens will not contain group membership IDs, yet these IDs are required for controlling access to pages and/or resources, applications have to call Microsoft Graph whenever a user action (e.g. accessing a page on the UI, accessing a todolist item in the web API etc.) takes place. These network calls are costly and will impact the application performance and user experience. As such, both the SPA and web API projects here would benefit from caching the group membership IDs once they are fetched from Microsoft Graph for the first time. By default, these are cached for **1 hour** in the sample. Cached groups will miss any changes to a users group membership for this duration. If you need more fine grained control, you can configure cache duration in [auth-config.ts](./SPA/src/app/auth-config.ts) for the SPA and in [appsettings.json](./API/TodoListAPI/appsettings.json) for the web API. If your scenario requires capturing real-time changes to a user's group membership, consider implementing [Microsoft Graph change notifications](https://learn.microsoft.com/graph/api/resources/webhooks) instead.
543543

544544
##### Group authorization policy
545545

5-AccessControl/2-call-api-groups/SPA/src/app/graph.service.ts

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@ export class GraphService {
5050
}
5151

5252
async getFilteredGroups(filterGroups: string[] = []): Promise<string[]> {
53-
const groups: string[] = [];
53+
let groups: string[] = [];
5454

5555
try {
5656
const accessToken = await this.getToken(protectedResources.apiGraph.scopes);
@@ -64,7 +64,8 @@ export class GraphService {
6464
groupIds: filterGroups
6565
});
6666

67-
return response.value;
67+
groups = response.value;
68+
return groups;
6869
} catch (error) {
6970
console.log(error);
7071
}

0 commit comments

Comments
 (0)