API SCOPES available to Course Home Widgets.
I'm trying to use the forceLogouts LP API call from within a course widget. But I keep getting response.status of 403.
I'm doing this so my Single Sign On Users will get forced logged out from Brightspace pulse which would normally hold their login for the 30 day tokens they are granted in Pulse. We want to just lock the Microsoft SSO and not change the student status on their courses. Bonus is we can manually force logouts of the system. Any help would be appreciated.
API Call:
PUT /d2l/api/lp/(version)/forceLogout/(userId)¶
This api call uses scope of sessions:session:delete
I've verified the API url and the userid exist:
version =1.49
userId is being pulled from subsequent enrollment API call and have been confirmed in the debugger to be valid in the API url at time of status !=200..
My code runs:const ForceLogoutUrl = /d2l/api/lp/${version}/forceLogout/${userId};
const response = await fetch(ForceLogoutUrl, { method: 'PUT'});
if (response.status !== 200) {
console.info(Fetch forcelogout error: url: available(${response.url}) status code: ${response.status}.);
return null;
}
Comentarios
-
That API requires that the calling user has a specific role permission that allows them to end the user session for any user in the system. It's not intended for a user to be able to end their own session. Which scenario are you trying to accomplish?
-
As @Joseph.W.983 said, if a user could use the force logout API route, they would be able to force log out any other user at will.
You might be able to use JavaScript to delete their session cookies and then reload their browser page, which wouldn't require any sort of role permissions.
-
I'm doing it as a FullAdmin system admin on the course. The course that holds the widget also has a restricted role for the users that I'm running the forceLogout. THe widget will be restricted to Full Admins. Users Role has basically all permissions turned off for the course. The key here is to also revoke the Tokens for the Pulse App not just the browser logins. Pulse will hold an account open for thirty days (You can launch a valid browser session even if you have your users SSO account locked, leaving a loophole for 30 days. If deactivate an account Pulse Still gets the course list and some other course related stuff. Using forceLogout gets around this making to the user can't see anything in Pulse, they would have to login again.
-
403 = the user making the API call does not have permission
User needs Setting "Can End Active Sessions" enabled.
Should see the End All Active Sessions option in the context menu of users' names in User Management
-
You are right it was off. I enabled. The setting is set at the Org Level so I moved the Widget to the Org level and adjusted my API calls.
Still getting a 403 error.
Remember there are two different API calls for this:
The Role setting says Sessions so I imagine it is not granting privelidge to forceLogout.
one forceLogout
PUT /d2l/api/lp/(version)/forceLogout/(userId)
and the other the Sessions:
DELETE /d2l/api/lp/(version)/sessions/(userId)
I'm using the forceLogout one.
-
Switched the sessions API call still get 403 error on organization Home Page.
Changed up the API URL and Changed the fetch to have method of DELETE:
so the url ends up /d2l/api/lp/1.49/sessions/numberofusersuserid.tried changing the DELETE delimited by single quotes to double quotes and no luck either. Logged out and back in to make sure my credentials where updated.
const ForceLogoutUrl =/d2l/api/lp/${version}/sessions/${userId};const response = await fetch(ForceLogoutUrl, { method: 'DELETE'}); // Fetch PUT data from the current URL
if (response.status !== 200) { //check response from API address for error
console.info(`Fetch forcelogout error: url: available(${response.url}) status code: ${response.status}.`);
return null;
} -
I'm not sure what scopes you exactly have from the widget. Inspecting local storage suggests that you have all scopes, but I ran into the same problem with the Grades scope. My conclusion was that the acces token you have only allows for GET requests to be made, not other types of requests. I ended up requesting an access token from javascript, using the XSRF token as X-Csrf-Token header value, somewhat like
async fetchToken() {
const xsrf = localStorage.getItem('XSRF.Token');
return fetch('/d2l/lp/auth/oauth2/token', {method: 'POST', body:'scope=grades:*:*',
headers: new Headers({
'Content-Type': 'application/x-www-form-urlencoded',
'X-Csrf-Token': xsrf
}),
credentials: 'include'
}).then(response => response.json());
}(disclaimer: adjusted to be standalone example)
-
Worked!
The localStorage.getItem('XSRF.Token') definitely made the difference.
The added proper scope (You show body:'scope=grades:*:*'' and I would have at least needed body:'sessions:session:delete'), didn't harm the fetch but it also wasn't required. Ran it successfully without the scope.
The added credentials: 'include' didn't harm the fetch but also wasn't required. Ran it successfully without the credentials.Having said that, having the scope and credentials does make the request a little clearer. The extra scope I'm guessing would ensure I always have the scope defined, it also better clarifies the call. Bottom line better safe then sorry.
@ron.kerkenaar was also right I needed the executing users role to have the Role Permission he mentioned (It is under Users), without it went back to a 403 error.
Ron Suggested: User needs Setting "Can End Active Sessions" enabled. Should see theEnd All Active Sessionsoption in the context menu of users' names in User Management.Thank you both, @ron.kerkenaar and @Allard.N.654 .
😎
PS: looking at the localStorage I can see my default scope, localStorage.getItem('D2L.Fetch.Tokens'), so with a little look there I can see if I would need to add the Scope to the request. -
Sorry forgot to note the widget can be run from any course as long as the running user has the rights to
"Can End Active Sessions".
The Pulse session isn't cleanly logged out it still lists all courses the logged in user had access to . and "View Descriptions" of modules still works. Pulse continues to show what is cached on the users device.
At the top of Pulse you currently receive a "Something went wrong, Awkward. We weren't able to fetch the latest information.".
-
Support indicates that there should be a hour before the app cache clears in Pulse after you run the API call for that user. Much better than the full access for 30 days (Unless you set the user to not be Active either via your imports or manually). Not everyone is using Single Sign On (SSO) logins and not everyone would have the same school practices. Some Schools would do it for students that haven't paid their fees in a timely manner.
