Are there other ways to disable access on API Explorer in App Engine, aside from having OAuth restriction?
Sample scenario:
Users who succeeded the verification process with OAuth are now eligible to use the API Explorer, although, this is not what the client wants his access of API Explorer to be, but rather disable the whole API Explorer in his App Engine entirely.
Is this something you can confirm or verify?
Thanks!
Based on your comments, it looks like you are referring to a feature of Google Cloud Endpoints Frameworks v1. I don't think a solution exists for that version to disable the APIs Explorer. However, this issue shouldn't occur when using Cloud Endpoints Frameworks v2. Because of that and since v1 is deprecated now, it sounds like your client should look into upgrading (see java migration instructions or python migration instructions).
Related
I have a Chrome extension that uses the Gmail REST API to send emails on behalf of the user. This API requires an Oauth2 token, which I'm retrieving using chrome.identity.getAuthToken.
The Problem
However, I am running into some issues with the Chrome Identity API. In particular, if the user authenticates with chrome.identity with a different Gmail account then the one they're signed into Chrome with, then they are prompted to re-login every hour or so (which doesn't happen if the accounts are the same). In addition, I'd like to minimize the number of permissions my extension asks for as a general principle (permissions sometimes introduce warning messages on install and risk disabling existing users on update), so I'd like to not have to ask for the "identity" permission if I can avoid it.
My Question
How can I authenticate the Gmail API in Chrome Extensions without using the Identity API?
Current Progress
I initially tried using Google's Javascript Client for auth, but that seems to be incompatible with Chrome extensions. After having searched other SO issues and some Google materials, it seems that the Identity API is indeed the recommended auth solution in Chrome Extensions. However, for the UX reasons mentioned above, I'm finding this solution problematic. And I do think an alternative should be possible -- for example, the MixMax Chrome extension, which uses the Gmail API, does not ask for the Identity permission.
Any help would be much appreciated! Thanks!
I've seen conflicting and stale information regarding whether Postman Chrome Extension is marked for deprecation or not. Could someone with direct knowledge address this question?
I need to know if I need to request that my work replace the extension with the native Windows app or not. Does the company intend to keep feature parity?
What's the difference between the Postman plugin and the extension? (since they are different)
The Chrome version of Postman is not using the same runtime for execution of requests & test scripts. It is recommended to transit to the native client. Especially when you plan to use Postman collections with the CLI client Newman.
You can read a blog post of the company on this topic here: Blog post on Chrome Extension vs. native app
We're encouraging Postman Chrome users to transition to the the Mac or Windows app when convenient, and to the Linux app when available, by heading to https://www.getpostman.com/apps and downloading the correct app. Going forward, we will be watching to see how Chrome OS app development proceeds, to make sure we provide the right tools for our community.
The new version of UFT 12.01 is supporting up to Chrome 36 when it comes to web content.
What about Chrome´s extensions though?
I read somewhere that they cannot be automated.
From the other hand side, when I use developer tools (12) I can identify buttons, textboxes etc.
Is it possible to test a Chrome extension by using UFT?
PS: I specifically try to automate one extension called POSTMAN - Rest Client (https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en)
UFT's Chrome support doesn't work with other extensions since Chrome disallows extensions being injected into other extensions.
As a workaround you may be able to use UFT's Insight option to automate any technology that UFT doesn't support directly.
Specifically for the Postman extension, this is a simple REST Client. I Assume you want to use it in order to test your REST services rather than actually testing the Postman extension. If this is the case wouldn't a more natural way to approach this issue be to use a UFT API test?
API tests support calling and validating REST services with all the functionality previously available in HP's Service Test.
I want to monitor Https traffic going out from google chrome.
Is there any possibility to write something in C++ for similar purpose, like some hook.
When I tried to hook in ws2_32::WSASend API and load my dll in chrome, it is causing crash. It look like chrome protects hooking of Windows API. I am more interested in APIs not applications like fiddler which can show Https traffic.
I have also seen google's native-client option but does not think it is useful because any extension need to deploy using google web store which is not a possibility in my case.
Has anybody succeeded installing locally Google's open-sourced API Explorer? I'm trying to use that tool to expose my company's API, and I find it difficult to get it running: compilation required some minor code changes and library upgrades, and at runtime, some pieces of JavaScript get downloaded from different google servers etc.
I was able to see the API by doing the following in Chrome Version 31.0.1650.63:
Hit the combination "Ctrl+Shift+N" to open a "New incognito window" (or use the "Customize and control Google Chrome" menu to the right of the address box)
Enter the URL in the "incognito" window
http://localhost:8080/_ah/api/explorer
After the page loads, click the shield icon that appears at the far right within the address box.
Click "Load unsafe script". The API appeared.
There may be a way to configure Chrome to get past these steps but I have not found that yet.
The opensource repository for the APIs Explorer is woefully out of date, that is partially if not entirely my own fault. I'll work on that.
That being said, the APIs Explorer is not really intended for exploring just any API. It will work well for any of Google's Discovery-based APIs, which happens to include APIs created by the new Cloud Endpoints service, recently demoed at Google I/O.