Recently something is changed the way Graph is handling permissions on drive items for external(outside tenant users).
Previously when we give access Write access to an external a unique link was created per user that we can do a patch call to update the roles if we want.
Now only two links are created one which is common for all externals having write role and one for read role.
I could not find a way if I want to update the role of an external from write to read or vice versa without removing all external users with write and adding them again.
Is there a work around to update permissions for external. The documentation is also pretty old its not updated since 2017.
Note: This is the Endpoint we are using/recommended to update permissions.
Related
I'm using Realm Swift and the Realm Object Server as the storage solution for an app I am working on. I could use a traditional server with a relational database, but I really don't need the server to do any real work. The only backend that I really need is just storage and data syncing. Realm seems to provide exactly what I want.
So far, I have a working example of a realm. The problem that I have started running into is access control. I feel like I may have a fundamental misunderstanding of what Realm can provide me, and there are not a ton of fantastic resources out there. The Realm documentation is pretty detailed, but it doesn't have the best working examples.
My app will be used to track teams from an available set of players. The set of players will be relatively constant and unchanging. The teams, however, will change frequently. With this in mind, I had the following idea of my Realm setup:
A single Realm containing the set of all players: /Players. Every user should have read access to this realm but only admins should have write and manage.
A single Realm for each user of the application /~/MyRoster. This realm should be read/write by that user. I think that the user should be able to grant another user temporary read/write access to their realm as well.
Multiple users should be able to form a team wherein they can read (and potentially write) all team users' rosters.
Does this sound like an acceptable use of the Realm backend? How should I manage the central shared data pool? Should I just create a /~/MyRoster realm for a user as soon as they register? How could I configure the permissions the way that I want them? To me, the permission structure seems very strange. It seems like I can use the PermissionOffer/PremissionOfferResponse constructs to achieve the Realm sharing that I want.
Any help would be greatly appreciated.
Thanks for the detailed write-up. Your proposed architecture seems like a good fit. Here is what I would recommend:
For the global /Players Realm, I would create that within development. Today this is a bit clunky in that you have to use a client SDK to open the Realm as an admin user (because only admin users can create Realms outside of their scope /~/ directory). You could create a code path in your app that if you sign in as an admin, this opens the /Players Realm and then apply a permission change to that Realm:
let permission = SyncPermissionValue(realmPath: "/Players",
userID: "*", // To apply to all users
accessLevel: .read)
user.applyPermission(permission) { error in
if let error = error {
// handle error
return
}
// permission was successfully applied
}
This code path doesn't need to be run more than once. Our plan is to add this kind of functionality into the browser in the dashboard so you can just manually create a global Realm and adjust permissions without using a client SDK.
For the user-specific Realms, you do not need to create them immediately, because the Realms will get lazily created when the user eventually needs it. What I mean is that Realm is setup such that you can open a Realm on the client synchronously (enabling the offline-first capability), and then after the first creation when the client syncs to the server, will the server actually become aware and also create the Realm within it. Thus you client code just needs to be setup to open the Realm at /~/MyRoster when necessary.
As for granting permissions to other users, this would use the Swift access control APIs to apply a permission change to the user's Realm and grant access to the other user. This can happen dynamically, such that the user can grant, then revoke the permission as needed.
For the third part with regards to groups, I would create another global Realm, /Group, that has read/write access to all users which holds the representation of the groups. For example you could have a Group object which contains a list property linking to User objects, with 1 User per user within your application. This way every user could make changes to the Realm to represent the groups he/she is part of.
You could setup a Realm Function to listen to changes to the /Group Realm such that when a user is added to a group or removed, the function would trigger the necessary permission change to the various Realms in the group.
Now if your are concerned about access control to the /Group Realm, you could instead, setup a Realm Function that uses an admin user to apply changes to /Groups, listening to a user-specific Realm /~/MyRequests where a user could write an object to this Realm which would trigger the function to make a change to the group Realm. In this manner you could prevent unauthorized requests, and keep the /Group Realm as read-only for all users but admins.
I continue to get a "HTTP/1.1 403 Forbidden" response from a PUT request to /d2l/api/lp/1.2/courses/7917 . This may be a permission problem with the user/role that I'm using, but I can't figure out what specific permissions may be required. Can anyone point me to a list or matrix of valence routes and required permissions? Or, answer for this specific one?
The same appid/userid/username works for the GETs associated with the same path.
confused...
cwt
The permissions associated with API calls should mirror the permissions you'd have to have if you were to perform the relevant function through the Learning Envrionment's web UI. You can think about this problem in two ways:
Frame the question in terms of a user role: identify the class of users you'd reserve this ability for in your existing configuration, and ensure that a user of that role can make the call through the API as you'd expect.
Frame the question in terms of an abstract single user: start with a role that has no privileges and add permissions until you arrive at only the ones required for the API call. This is not a trivial exercise, and the first way is far more useful in the long run.
In this particular case, because the API requires you provide a complete course offering set of properties when you want to update it, you have to have permission to alter all the properties in the set (under the Manage Courses tool). You also need to be able to see the course info in the first place, so you need to have Course Management Console > See Course Info as well.
You're probably safest to look at the permissions array in the Manage Courses and Course Management Console tools for the user roles that would do this thing in the web UI and make sure that the users employing your app also have a similar permissions array specified in those tools.
I'm working on migrating from SOAP to valence API. I'm having some problems with a few calls like getting users (All users, based on role, by userID, etc) and grades (All variations).
I see an empty list returned with no items. There's no error of any kind. When I try to get the data using SOAP, I get the desired data.
I've checked the permissions for "Search for Students", so technically, I should be getting something when I try to get all users or by role id of students. What else am I missing here...
The D2LWS service's authentication mechanism puts the API caller in the position of being a privileged caller. The Valence Learning Framework APIs use a different auth model: the user ID/Key tokens that identify a user get employed by the back-end to restrict the functionality of calls. That is: the authenticated user should have access to the same functionality and data as the user would get through the web UI, and no more.
In this particular case, the calls succeed: they send back all the elements in the result set that your calling user has privileges to see -- none of them.
This is almost certainly an issue with the role privileges afforded to your calling user, and debugging the permissions around calls can be challenging. The Valence project's documentation provides a walkthrough topic on investigating role permissions that might shed let on a possible approach here, especially with respect to the calls to gain access to user records (or properties that appear in user records).
As the walkthrough discusses, there are various aspects to making the general call to /d2l/api/lp/{version}/users/ that bring permissions into play:
If you're trying to filter with a query parameter, does the calling user context have permissions to use the data on which you want to filter
Does the calling user context have permission to see properties affected by User Information Privacy settings
Does the calling user have permission to search for all the user roles they need to, in order find users in the result set
The users call operates on the root organization unit, so the permissions the calling user requires must be set on the organization org unit type.
By contrast, the Grades-related API calls operate not on the root organization unit, but typically on course offerings, sections, or groups. The permissions surrounding the calls there will get checked in the associated org unit types, so the calling user will need the right permissions against those types. Additionally, many of the calls related to course offerings (also sections and groups) require that the calling user be enrolled in the org unit in question (and in some cases, explicitly enrolled, not merely enrolled by cascading enrollment).
If you're sure that your calling user context does give you access to these things (and allows you access to this data through the web UI), and you still see a mismatch like this when you're calling through the API, then you may have uncovered a defect of some kind and you should please ask your organization's support contact, or your account manager, to open a support ticket to report that through Desire2Learn's support desk.
I have a list in my sharepoint site.The users who have contribute access is able to add items on the list.But recently some users who have contribute access was not able to add new item.The normal work around we do is we will add them to the owners group and ask them to login .Then we ask them to logout and remove them from the owners group and issue will be resolved.But the proper way shouldn't be like that.Please give the proper way to solve this issue.
The users whom you talk about, Were they added to the contribute group recently? May be the list is not inherting permission(?)
You can use this WebPart (http://accesschecker.codeplex.com/) to check individual acces to every list, lib etc in your SharePoint site.
I'm bit vague about how to start using the shiro plugin, after reading few documents. I decided against Nimble, as it comes with few tables and UI plugins.
I setup shiro plugin with wildcard realm, with my own tables. I may use permission based (rather tan role based) access control as it scales well. Now, the steps for it.
assign the permission string to the subject, and save it in the db
check the permission through isPermitted, hasPermission (or relevant tags in GSP).
Now,
1. when to use the accesscontrol through filter?
2. is there a closure injected into the controller where I can define the permission for the actions in it? I read somewhere about accessControl static closure on each controller, but not seems to be documented.
3. How do I create a typical access control scenario like only the creator of (something, a post etc) can delete it? One possibility is creating and persisting a permission string based on userid. to check the permission retrieve the object (post), get the userid and compare with subject.. seems bit complicated.. any easy implementation?
thanks a lot..
Babu.
1 when to use the access control security filter?
A. Use accessControl{true} when you want to limit access to controller actions to authenticated users.
B. Use accessControl() when you want to limit access to controller actions, regardless of parameter content, based on permissions "${controllerName}:${actionName}".
C. When you want to limit actions based on parameter content, e.g. only delete a domain object for which you have the delete permission "${name}:${id}:delete", you need to check isPermitted explicitly in the controller.
3 How do I create a typical access control scenario like only the
creator?
I would add a the necessary permission(s) to the user when the post is created, e.g. "post:${postId}:*" This way the permissions belong to users and/or roles, and not to arbitrary domain objects, as intended in the Shiro way of working. As opposed to file system permissions, which belong to files and directories instead of users.