Gsuite resources can't be shared with service account - google-calendar-api

I'm trying to fetch rooms (added from calendar.google.com) service account (created from https://console.cloud.google.com/iam-admin/serviceaccounts) in spring boot project.
I had one service account which I created 4-5 month ago, it was working and it is still working with the 3 specific rooms.
But if I add service account mail to other rooms, then these rooms are not returned in the project.
I did all the steps written here:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
https://support.google.com/a/answer/1034381?hl=en
Also, I tried removing the service account email from the room's "Share with specific people" list in Calendar, and then added it back (this helped sometimes in the past).
But the re-added room was also not returned in my project.
I'm using this method from java to get the rooms.
https://developers.google.com/calendar/v3/reference/calendarList/list
This look like a bug, so do you know how can I work around this?

If you shared the resource calendar with the Service Account through the UI, by adding the corresponding email in Settings and sharing > Share with specific people, the calendar might not have been added to the CalendarList.
In order to make sure that a calendar is added to the CalendarList of a Service Account, you should use the API and call calendarList.insert.
Update:
There are currently several open issues in Issue Tracker regarding Service Accounts in Calendar. The situation you are experiencing is most probably related to that: check this, this and this, for example.
Meanwhile, I don't think using the API can be avoided. Maybe you could develop some kind of UI to make it less painful?
I hope this is of any help.

Related

Google Scope Authorizations Loop Endlessly When Previewing or Publishing Apps with Cloud SQL Database

My organization set up Cloud SQL as the default for Google App Maker about one month ago. In the last week, we have been unable to preview or publish apps that use Cloud SQL data sources, including the sample applications which worked perfectly before. The failure occurs during the authorization process. When previewing or publishing an app, Google App Maker displays a dialog stating "Deploying this app requires authorization". Next it prompts the user for their Google account and then requests approval for the necessary authorizations (e.g., "Manage the data in your Google SQL Service instances"). After approving the authorization, the prompts to authorize begin over with the dialog stating "Deploying this app requires authorization".
Observations:
We have repeated this problem on multiple different computers, networks, and four different user accounts.
In the SQL cloud console, our Cloud SQL instance shows new databases being created for each app along with new database-specific user accounts
All of the databases appear as expected when I log directly into the Cloud SQL database using phpMyAdmin
Other apps which don't use a Cloud SQL datasource work fine, including an app that uses a calculated data source which is hosted in the same Cloud SQL instance
The only errors in the Stack driver logs for the Cloud SQL database showed "INFO" level communication errors with the database (aborted connection...Got an error reading communication packets)
I'm unable to find Stack driver logs for the apps because I cannot preview or publish them (either option would provide a link to the Stack driver logs)
There are now approximately 20 databases in our SQL instance (mostly associated with simple app tests) and we have only used 1 GB of 10 GB of space in our SQL instance
I haven't seen any related problems on the Google Issue Tracker for Google App Maker
I'd appreciate any help or suggestions on what to check in order to resolve this issue.
I posted an issue to Google Issue Tracker and Google corrected the problem. They also provided a workaround if this problem happens again.
Here is the response from the Google development team posted on Google Issue Tracker: https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
Contact someone in your domain with Admin powers for your Google for Business license.
Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
Identify the Organizational Unit of that Appmaker dev user and make a note of it.
Under the Organization Units settings, locate the Organization Unit you identified above.
Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
Be sure to select ONLY the OU you intend to change.
Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.

I am a app developer and I am unable access Create Passenger Name Record API

I have sent couple of emails to support team for become a sabre customer, I have submitted the application to get the access at following link.
https://www.sabretravelnetwork.com/home/solutions/travel_agency/contract_selector/without_arc2
Pls let us know if I am missing anything?
Thanks
Access to the PNR (Passenger Name Records) requires a contract with Sabre. They only give this access to travel agents or companies writing services for travel. There is also associated fees. Also you need to be aware there are costs for every PNR you create. So its not as easy as just getting access to the PNR.
I know this is not the answer you want but its how it works.
If your just trying to build out a small booking engine I would suggest getting into Expedia's API toolkit. Much easier and allot less expensive to get into.

Available Miicrosoft Cognitive regions

I'm looking for a Voice Authentication API, and I find Microsoft's one.
When looking at prices, it asks you for a region. The problem is that
it only shows a region
I've been reading about Azure's regions, and it say that is where data is stored, so my question is if it would be possible to use it in a different region than allowed.
Thanks (and sorry for my spelling mistakes).
Quick Answer:
Normally yes, but currently the Speaker Recognition API is only offered out of the WestUS datacenter.
If it's mandatory that you have low-latency when using the service, I suggest you look into setting up and/or temporarily subscribing to a CDN service. Or, if you have a lot of time on your hands, and know waaaaay more than I do about this subject, you may be able to design a local cache to mitigate latency if you're distant from WestUS.
Less-Quick Answer:
First off, you should use the dashboard interface at https://portal.azure.com to sign up. You will first need to create a Pay-As-You-Go subscription as your payment-medium, but it will give you much more control over & visibility into your service.
Here's what the signup pane looks like inside of https://portal.azure.com:
It appears that, in it's current "PREVIEW" deployment, you are right the services is only offered from the the WestUS data center. Normally you will have the option to one of ten's of global datacenters, but it is common that PREVIEW services aren't deployed globally until they're out of PREVIEW status.
If the problem you are looking to remediate is latency-based, look into the CDN suggestion in my "Quick Answer."
If your issue is about getting different pricing based on your location, the location of the datacenter you choose will not affect this. If geographic-discounting applies to you, it is based on the country that is assigned to your Microsoft Username/Password combination at the time it was created. This value cannot be changed once a username/password combo has been created, and consequently, any payment info used along with this uname/pass will need to have a billing address in the same country.

APIGee cannot retrieve application keys for account

I use APIGee for both API Proxy and Documentation, using a customized documentation site.
Following the recent APIGee outage this weekend, when I access my registered application list using my personal login on the documentation portal, I can no longer retrieve my application keys.
I get the error
STATUS: 404 - Not Found; Communication with the Apigee endpoint is
compromised. Cannot get API Products List.
The strange thing is that if I use my admin login at accounts.apigee.com, I can see 2 of my 3 applications listed... but one has disappeared. And more worryingly, this portal provides different application keys to the ones that were initially provided though the documentation portal.
I haven't been able to find any good documentation on this. How are these two sites linked together? Why are the keys different on both sites? What has caused my data to go missing?!
Tadhg -
This sounds like an issue that needs investigation by Apigee Global Support.
Would you please create an Apigee Support case? Please provide any applicable details, including your Organization name, the API call(s) you are making, the 3 applications you expect to see, and any other details you think might be helpful to diagnose.
Thanks!

Integrating an issue, feature request and bug tracking system into an existing ASP.NET Web App

I have an existing asp.net application that is currently in production for more than 3 years now. That application was developped based on internal and user requirements. That application is also using Google Analytics to detect different usage metrics to understand more what users are doing and which part of the system is most requested. But... we understand now that we are not so well connected to client's need's and more importantly, we don't receive a lot of feedback from them and when we receive feedback, that feedback is sent to many different people so most of the time they are lost or missing some valuable informations. Here is my question: is there some free (or paid) products that can be incorporated into an existing asp.net application that can provide the following functionnalities:
For my users:
Send feedbacks
Log bugs
Submit feature request
Ask questions
Be able to follow an issue, bug or feature and subscribe to it
Be able to rate answers
Be able to include attachments
Be able to vote for issues to prioritize them
Etc.
For me:
Respond to all of these issues and be able, in some way, to see and analyze all of this data to properly populate our product backlog with what user needs
My real need will be to have something like Telerik has implemented. Is there something that can be incorporated into an existing application?
Thanks in advance
What about User Voice? It's a great system to collect user feedback. Not sure if you'd get the integration you're looking for. For the rest of your requirements it seems it would work really well.

Resources