On the Google admin console, when looking at chrome devices, you can see their "OS version policy compliance", as seen in the image below:
However, when retrieving a device from the directory API (using https://developers.google.com/admin-sdk/directory/reference/rest/v1/chromeosdevices/get), this field does not seem to be returned. My assumption was that the directory API was able to return anything you could see in the admin console. Do I need to use a different API to retrieve this information?
Update
I have added this feature request to get this added to the API, as it looks like it is not currently supported.
As of today, Google Workspace Admin SDK does not support retrieval of OS version policy compliance. An alternative solution is to use the value of osVersion in the response body of Method: chromeosdevices.get and compare it with the OS version specified by your organization's policy.
Note: You can only use the alternative solution to check whether the device is Compliant or Not compliant since you are only comparing OS versions.
Related
We are using Google Cloud triggered builds (refer documentation) and are successfully able to see results like:
https://VERSION_ID-dot-PROJECT_ID.appspot.com
We use API keys for Maps etc. and would like to restrict access to websites. For this, there's wild card allowed in API Credentials page (refer documentation) for ex:
https://*.example.com
however, it doesn't allow:
https://*-some-random-string.example.com
We would like to overcome this issue so we can restrict the keys to our PR builds only, how do we do this?
One option would be to have PR builds like:
https://VERSION_ID.PROJECT_ID.appspot.com
so we could use https://*.PROJECT_ID.appspot.com in API Credential restrictions, but I can't figure how to create PR builds as sub domains.
Any help would be much appreciated!
Answering my own question:
GCP does indeed allow patterns in URLs for Credentials:
*-some-random-string.example.com/*
The reason it wasn't working for us was something else, and not this capability.
I have access to our corporate PCF, though both the Apps Manager webpage and the "cf" CLI (and thus the API).
How can I detect what version of PCF they're running? There's nothing in the website that lists it, and the best I can find is using cf api which returns:
api version: 2.98.0
How can I map that to the PCF version, or is there another way to detect it?
Usually via Ops Manager however another quick way is to click on the 'Docs' in Apps Manager it should take you to the documentation of relevant PCF version. For ex: https://docs.pivotal.io/pivotalcf/2-6/pas/intro.html means PCF 2.6
Please be advised that documentation link requires to be updated during upgrades so if someone doesn't do - it will be pointing out to older version..
I don't believe Apps Manager or the API (i.e. Cloud Controller) will report that information. Both are just single parts of the entire system, so I think you could really only expect them to publish their own version information.
If you want to see versions of what is installed, you need to look at Ops Manager. That will show you the tiles that are installed and each version.
If you don't have access to Ops Manager, you'd need to ask your platform operators.
Hope that helps!
I'm looking for API documentation on how to interact with user accounts. For example, checking if a user exists, creating a user, updating a user, getting user properties. I've been to doc.sitecore.net but I still can't seem to find any of this documented. Is it documented and where can I find it? If it is not documented, what other resources can I access?
In 6.x versions, I see that some of the functionality I need is in Sitecore.Security.Accounts. However, I don't know if this is still current or if there is a better method for 8.1 and future versions.
The 6.x guidelines are still the most current, and as of 8.2, there has not been any major changes to that API, so the Security API Cookbook is still your best bet.
https://sdn.sitecore.net/Reference/Sitecore%206/Security%20API%20Cookbook.aspx
To my knowledge, this part hasn't been changed since Sitecore 6.x, so you should be safe to use this resource.
I have installed the basic jUDDI Server in my machine. I am able to Register the Service and able to read my Service info as a new user. I want to restrict the users who wants to look up my services. I want only my clients to access these information. I want to authenticate them so only my clients can view the business, service, tModel, Binding Template information. How can I achieve this? Can any body help me get through this?
Try turning on the setting the requires authentication for the inquiry API. You can find it in the juddiv3.xml config file for the server. Here's the xpath to get you there.
config/juddi/auth/Inquiry=true
Future readers, the documentation is located here for the current release (as of this time of this post)
https://juddi.apache.org/docs/3.3/juddi-guide/html/ch04.html#_administering_users_and_access_control
but the website https://juddi.apache.org/docs.html will get you to whatever is current. The docs (that website) is also available as part of the distribution and (i think) maven artifacts
This is on Mac 10.8
I have written Google Chrome Extension and a Native Messaging executable which communicates with the Chrome Extension using Native Messaging. All works fine with my Proof of Concept as part of development.
Issue is that now I want to get it deployed.
I have my in house installer which by which I need to create a com.my_company.my_product.json manifest file inside of this /Library/Google/Chrome/NativeMessagingHosts directory which cannot be accessed unless I ask for the password of the admin user.
I am doing this port as part of migration of NPPlugin to Chrome Extension Native messaging communication which will replace the NPPlugin. NPPlugin can be accessed from both /Library as well as ~/Library which does not require sudo permissions.
Why does the manifest file need to be at root /Library level ad not user ~/library level? If so how can we get this installed on a Mac without bothering the user with admin password which the user will obviously be less likely to share.
If anyone has a solution, the Native Executable is a C++ program that can use Mac API calls.
Your understanding is correct. The Chromium team is investigating user directories as an additional option. Ensuring continuing security is the primary concern. I'll update this answer when there's more to report. (Update 6/1/2014: see Rob W.'s comment to this answer)