What are the distinct consequences of setting readwrite or readcreate as values of access property for permissions entry in the manifest of a Firefox OS app?
Those permission access values in the manifest are used currently by two APIs, Contacts and Device Storage. For example if your app needs to only read the phone contacts, you have to set "readonly" access. If you set "readwrite" for no good reason (your app doesn't need this higher level of access), your app might fail the review for being added in a marketplace. Another example is if your app just needs to export a contact and save it to the phone contact list. In this case you need to set "createonly". With this setting in your manifest, trying to read or modify an existing phone contact will fail. "readwrite" will allow you to both read, modify and create contacts. "readcreate" will allow you to just read and create contacts.
With those permissions set, the user will be prompted if he wants to allow the corresponding operation. The access levels methods are fine-gained so that the user has more control over what the application can do with his contacts/files.
Related
I'm developing a Gmail Add On with Google Apps Script, which is intended to be used only by enterprise accounts (Google Workspace Accounts).
One of the requirements of the app is that when the Admin installs the app for all its users, they have to configure some organization wide configuration values (a license key for example).
I tried with the following code:
const userProperties = PropertiesService.getUserProperties();
userProperties.setProperty('licenseKey', '[TOKEN]');
But when I do this, the data is only accessible for the current user (and therefore I would need every user to know this key in order to save it on the configuration variables). I'm looking for an option in that a user saves this setting variable and then everyone on the domain can read the saved value.
I am considering to create an app for the first time and I am not sure I understand google‘s terms and conditions well. According to what I read, if I give access to some users, I will not be able to get it back and besides, google will get the right to distribute it further. Is this right?
Creating a WebApp with limited access
When you deploy a WebApp you can choose how to execute the WebApp and who has access to it:
You execute either as
You
The user accessing the App
And the App can be accessed by either
Only you
Anyone in your domain
Anyone
You are not able to select only specific users to have access.
However, obviously only the users with whom you will share the WebApp URL will have access to it.
Also, you can use within the WebApp the method getActiveUser() to retrieve the identity of the user and implement a conditional statement that runs the rest of the script only if the active user is one of the "allowed" ones.
Very important: After deploying the WebApp for the first time, you can deploy it as a new version as often as desired and change thereby the execution and access permissions which makes it easy to revoke access
Using the app script properties service I can allow users to store some settings information. I understand that these are stored for a given user for a given script. As the admin is there anyway for me to review all the users properties?
Also does anyone know if you are allowing the script to run as you (the publisher) does the user properties store as the user accessing the script. I know that the session data is for the actual user and not the publishing user(even when running as the publishing user).
Thanks
I'd like to suggest storing the user properties in Firebase. This will give you full access to them as needed, and they load really fast for the user. My two go to docs for this are this one to get the library and this one to as for details. If this is not possible, an alternative could be to append a row to a google sheet each time the user updates their users properties. I use both of these approaches for also tracking detailed app usages.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
Participating Components:
(all in the same project)
Android App
Web App
Service Account
The users have authorized the app on their Android devices with Cross Client Identity:
oauth2:server:client_id:[web_app_id].apps.googleusercontent.com scopes ...
Flow:
Several users request the creation of the same file through the Android app ( a file for every user is not desired, see "Known workaround" )
A service account then creates that file ( service account is owner )
Service account shares that file (by link and explicit with users)
User authorized drive service / or service account that impersonates a user tries to copy that file to the user's Google Drive ( User has to be the owner of that copy in the end)
Error:
This fails with scope drive.file ( and also drive.readonly ):
Error Message:
The authenticated user has not granted the app [project_id] write access to the file [file_id]
(btw: why write access is needed with copy()? giving users write access to the file does not change this error)
Known workaround:
It works with full drive scope
( but: my app does not need to see files it has not created - so i want to avoid it)
Same result can also be achieved by re-inserting the file instead of copying it
(this overhead is important for my app though, cause same file might be requested by multiple users)
An explicit interaction with a file from a UI Picker or so will propably not work as the file will have to be created after requesting it. also i can't think of a way how to do that without decreasing usability of the Android app.
Expected result:
www.googleapis.com/auth/drive.file: Per-file access to files created or opened by the app
It seems to me this should be enough.
As the file is created/owned/shared by my app's service account.
and copied by my app on behalf of the user.
www.googleapis.com/auth/drive.readonly Allows read-only access to file metadata and file content
At least this one should work as it should give read access to all files which should be enough to copy a "shared with user" file created by an "authorized by user" app.
Question:
the Web Application and the Service Account are in the same project.
Can the Web Application act like a Service Account on behalf of a user? if so - i don't know how. Would that make a difference anyway?
This seems like a Bug to me in this special use case, as the same result can be achieved with a workaround. At least scope drive.readonly should allow my app to copy app owned files to the user's drive.
Making a copy through the plain Service Account and then changing the owner of that copy to the User would be another workaround, but that fails too.
I must be missing something simple.
Please guide me.
Thank you.
I had the same problem and resolved it using the drive.metadata in combination with the drive.file scopes. Related question