[google-fit]; write my blood sugar data to Google Fit, but something went wrong(REQUIRES_APP_WHITELISTING) during the test - google-fit

"OAuth 2.0 Client ID" was successfully obtained,but "OAuth consent Scree" was not verified
FitnessOptions fitnessOptions = FitnessOptions.builder()
.addDataType(HealthDataTypes.TYPE_BLOOD_GLUCOSE,FitnessOptions.ACCESS_WRITE)
.addDataType(HealthDataTypes.TYPE_BLOOD_GLUCOSE,FitnessOptions.ACCESS_READ)
.build();
DataSource mDataSource = new DataSource.Builder()
.setStreamName("test")
.setAppPackageName(context)
.setDataType(HealthDataTypes.TYPE_BLOOD_GLUCOSE)
.setType(DataSource.TYPE_DERIVED)
.build();
DataPoint bloodGlucose = DataPoint.builder(mDataSource)
.setField(HealthFields.FIELD_BLOOD_GLUCOSE_LEVEL,15)
.setTimestamp(now.getTimeMillis(),TimeUnit.MILLISECONDS)
.build();
DataSet dataSet = DataSet.builder(mDataSource)
.add(dataPoint)
.build();
Task<Void> response = Fitness
.getHistoryClient(context, GoogleSignIn.getAccountForExtension(context, fitnessOptions))
.insertData(dataSet);
I've passed the GoogleSignIn permission and an exception(com.google.android.gms.common.api.ApiException: 5024) has occurred when inserting data
please see: [https://developers.google.com/fit/scenarios/write-blood-glucose-data]
Does not allow the user to write blood sugar information anymore? or maybe there's something wrong with my code.
I would be very grateful if you could give us some suggestions based on your rich experience.

May be a little late, but if anyone else runs into this, the following may be of help.
From Google Fit docs:
Google Fit has health data types for measurements related to managing
general health (as opposed to fitness). Because health data can be
sensitive, these data types have sensitive scopes. This means you need
to apply for OAuth API verification for sensitive scopes on top of the
standard authorization permissions for Android and REST to read and
write to these data types.
Google will review your application and grant or deny verification.
Users will review the scope requests and grant or deny access to
these.
Note: Google has temporarily stopped taking new requests to write to health data types. We are updating our policy and process for
reviewing requests and will update this documentation again when we
resume.
As at 1 Jun 2021.
https://developers.google.com/fit/datatypes/health

Related

Google Workspace alert or API to be notified when users are about to reach full storage

I do not see anymore in Google Workspace interface a way to receive alerts when users are about to reach their storage limit (only end users receive alerts). is there any setting I can use to receive this alerts as an Administrator or any API that will let me do that?
I have been reviewing the documentation for alerts and also storage settings in the Admin console. It seems like as Administrator you can only see the list of users and filter out of storage users.
You can view this Help Center for reference.
Unfortunately a setting like that is not available at the moment. It would be a great idea to share the feedback for something like that in the future. If you have a Google Workspace account you should be able to request access to the feature ideas portal and send the feedback
You can give your feedback or request a feature over here:
https://www.googlecloudcommunity.com/gc/Feature-Ideas/cmp-p/grouphub%3Aworkspace-ideas-group
Utilizing API or App script can help you to manually make a call and pull some of the data of the users and their storage, for example:
function getStorage() {
var about = Drive.About.get();
about.quotaBytesByService.forEach(function (s) {console.log(s)});
}
It should give you the usage of Drive Storage in all services that take space. You can also utilize the Reports API, to gather used quota in percentage of the users quota storage using the "used_quota_in_percentage" as suggested by the documentation. You can test it here
You can add the parameter from the screenshot for all users or specific users and try to filter it in case you are looking to implement it in the future:

Cloud Schedule + Cloud Functions -> Gmail API watch() - WORKING NOW

This is my first post here. I am sorry if it's a repost, but I've been searching for more than one month for the answer to solve my problem in all websites and forums and until now... no answers!
My goal is to make a Gmail pub/sub watch() to make an action whenever I receive a new email.
To do so, according to the developer's website, I need to subscribe to Gmail watch() on a daily basis with the code:
request = {
'labelIds': ['INBOX'],
'topicName': 'projects/myproject/topics/mytopic'
}
gmail.users().watch(userId='me', body=request).execute()
Until now i have this a working scheduled task with a service account, with INVOKER Permissions. This part just works fine.
In my "initial autorization function" i have:
const {google} = require('googleapis');
// Retrieve OAuth2 config
const oauth2Client = new google.auth.OAuth2(
process.env.CLIENT_ID,
process.env.CLIENT_SECRET,
process.env.CALLBACK_URL
);
exports.oauth2init = (req, res) => {
// Define OAuth2 scopes
const scopes = [
'https://www.googleapis.com/auth/gmail.modify'
];
// Generate + redirect to OAuth2 consent form URL
const authUrl = oauth2Client.generateAuthUrl({
access_type: 'offline',
scope: scopes,
//prompt: 'none'// Required in order to receive a refresh token every time
});
return res.redirect(authUrl);
};
My issue now is that the access token is generated via (prompt) the first time and never updates to a new one ( the token expires after 1hour...) it means this code stops working after that period and a "manual" intervention is required. According with the documentation, i need to use "offline" method and on "prompt" i can omit (only requests permissions on the 1st time) or none (never asks), like is said here.
I managed how to make it work! tomorow i will continue with the process.
Should i post here my working code for reference?
Thanks!
I will rephrase the process you illustrated so that there is no ambiguity.
According the documentation you pushed:
You do not suscribed to watch(), you call watch()
watch() is an API call to the Gmail API that will enable automatic events publication on a pub/sub topic you define given conditions you specified. Who are you watching? On what events?
You suscribe to a Pub/Sub topic that is targeted by your previous watch() call
A process (e.g: Google cloud function) suscribes to the topic and will consume messages sent by the Gmail API
The call is to be renewed at least every seven days
Because Google needs to be sure you still need to monitor the targeted inbox, it needs a renewal from you. Another watch() call will act so.
Cloud scheduler will enable this periodic renewal
this service will trigger your renewal script you put in your question. To do so it needs to be authenticated to the platform that host the script. It is easier if your script is hosted in a google service (cloud function, cloud run,...) and the authent type depends on the target URL form. In all cases YOU DO NEED an authent token in your request header. The token is generated from a service account you created with the right permission to call your script (e.g: cloud run invoker). By default the scheduler has the right to generate a token from it
So far so good. Now comes the tricky part and you don't mention it in your question. How is authenticated your gmail api client? You cannot monitor someone inbox, unless this person gave you the permission to i.e you call the API with the right Oauth2 token. Indeed in the video you point they authenticat the user using this principe which is implemented in their code with Express-oauth2-handler.
So you will have a cloud function to init end user authent and watch to his/her inbox. The renewal should do so but problem is user will not be there for accepting the end user consent. Here comes the offline access but it is beyond the scope of your question. Finally a second functions will suscribe to the pubsub topic and consume the message as you need. See their implementation code which populate a spreadsheet.
The documentation you shared in the comments does not say that you can remove the token from the headers of the service account, also the gmail API documentation you also shared says that you only:
need to grant publish privileges to gmail-api-push#system.gserviceaccount.com. You can do this using the Cloud Pub/Sub Developer Console permissions interface following the resource-level access control instructions.
In order to achieve this basically what you will need is a setup of two cloud functions, the first scheduled function is responsible for setting up the watch(), and you can check this documentation for how to deploy a scheduled function, and the second function being triggered by the pubsub of gmail notifications, you can check this documentation for how to build an event triggered function. Both processes are similar.
NOTE: I have never user the Gmail API, so I am not sure if any extra steps are necessary but then again, the documentation implies that setting up the permissions of that service account is enough to make it work.
EDIT:
As per the information you have shared. The issue is likely that you are not properly setting the Service Account to authenticate with the Cloud Function. As per described in the documentation, you have to grant to the Service Account the role Cloud Functions Invoker in IAM.
Let me know if this fixed the issue.

Service now api how to comment as specific user

I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.

Document List API to Drive SDK and Client Login

We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account

How to learn to handle HTTP requests of protected resources?

I've wrote a tiny script that retrieves publicly available data from some APIs, in JSON format. I'm now trying to get some protected data out from bit.ly (click stats from a given user) and so I obviously need to authenticate via OAuth.
I don't seem to understand the role of client id and secret, as well as the user API key. I also don't get how to grab an access token (maybe generated during OAuth authentication?) to authenticate my HTTP requests of protected data. Do you guys know any good (e)book, article or any other resources I should read to understand in detail these architectural nuances of authenticated data retrievals and HTTP requests?
It is exactly as you suspect. The access token is granted during the OAuth process, which is basically a three step rocket of getting
Temporary credentials for your application
An end user needs to authenticate those temporary credentials, which grants you a verifier token
And finally you exchange your temporary credentials and the user verification for an access token.
Depending on which language/framework you are using, there are often good libaries available to help you implement an OAuth client. Check out: http://oauth.net/code/
But you will be well served by a clear understanding of how the whole thing works. Twitter has a great tutorial about OAuth 1: https://dev.twitter.com/docs/auth/oauth.
Regarding OAuth 2. Check out http://hueniverse.com/2010/05/introducing-oauth-2-0/. Hueniverse is a good resource for all things OAuth by the way.