How to create an own Google Oauth Scope (writeonly)? - oauth-2.0

My goal is to have a Google (Drive) Oauth Scope which gives the permissions of writeonly. I can't find it in the google drive oauth scopes list.
So is it possible to create a own scope? -Or is there another solution?
Thanks in advance for any help

You cannot create a scope that is not already documented. In your case there is only readOnly or readWrite.
if it applies to your case, you may use the individial file-level drive scope which only gives access to specific individual files including newly created files by your app.
Note that write-only doesnt make much sense as a permission since editing the file would require to have access to the original content, unless its append-only (not supported) or create-only (file scope has this)

Related

How to set proper google oauth client scope that don't need any access right of end user data?

I am learning to access Google Sheets using Python (c/q gspread)
my current script is as simple as one from here.
gc = gspread.oauth(
credentials_filename='path/to/the/credentials.json',
authorized_user_filename='path/to/the/authorized_user.json'
)
It displays a login screen like:
That screen tells my enduser that my script will able to:
See, edit, create, and delete all of their Google Drive, and/or
See, edit, create, and delete all of their Google Sheet spreadsheets.
I'm pretty sure that two things will scared my end user.
Is there any 'scope' that will only give my script to a sheet that shared to my endusers account and the access right is following what sheet owner set for each endusers.
The best scope to use in your case is https://www.googleapis.com/auth/drive.file. This is a flexible scope that will be granted individually in a per-user basis.
Of course, if you want to be as restrictive as possible the best scope is https://www.googleapis.com/auth/drive.apps.readonly, but its functionality is pretty limited (as the same says, only reading and no editing).
You can read more about the different scopes here.
Unfortunately, you cannot get rid of the authorization screen, you can read how Google authorizes access to the APIs with OAuth here.

Graph unable to update permissions for an external user

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.

What are the permissions required in desire2learn (D2L) Valence PUT call for .../courses?

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.

How can I access the name of the user running a script embedded in a shared spreadsheet?

I have a Google Spreadsheet containing a script that I wrote. The script updates a per-person sheet named after the logged in user, or creates a new one if it's not there yet.
I shared it in "can edit" mode with other people, expecting the code accessing the user name to work as it did in my case, but apparently it doesn't.
Google Apps Script seems to contain three ways to get the name of the current user:
Session.getActiveUser()
Session.getEffectiveUser()
Session.getUser()
and all of them return the empty string when I'm not the user running the script.
(Btw I'm having a hard time to tell the difference between them...)
Considering that I'm sharing this spreadsheet in read/write mode, I would be a bit surprised if this was an intended security method... it's not like I don't know the emails of the people accessing the spreadsheet I've explicitly shared with them... Plus, Google is asking for permission anyway, couldn't it ask for permission to access the user name as well??
Is there a way around this?
Is there a way around this?
These methods only work if you're using a Google Apps account and you're on the same domain as the user. If not, then there's no way to get the user id. AFAIK Google removed this feature completely for regular accounts. You may try to argue with them opening an issue here.

Grails Shiro plugin : confirming my understanding

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.

Resources