I'm writing a Chrome extension that will access Gmail API, and I need proper authorization for it. All code examples involve referencing their API Javascript library which loads their oauth library dynamically, like gapi.load('auth2', ...). However, after switching to the v3 manifest, they are going to forbid executing downloaded code, so the only option would be to include the required scripts with the extension.
How do I implement it? Would I have to implement calling the API endpoints myself?
Related
I am using vuejs which runs as a single page application in the browser, so any API calls I am making are using axios. Unfortunately googles APIs block any requests through axios due to CORS. I have tried various npm packages to try and solve this, including "official" google maps package, but I still run into CORS issues.
I am positive there must be a way to do a placeid search through the browser using one of their javascript libraries, but I can't for the life of me find any good articles or examples to see how it is done.
I have google autocomplete working, and creating google maps through geocode is no problem, just can't find anything related to placeid search.
Here is an example of the request I am trying to make taken from googles docs.
https://maps.googleapis.com/maps/api/place/details/json?placeid=ChIJN1t_tDeuEmsRUsoyG83frY4&key=YOUR_API_KEY
Can anyone provide a solution or link to an explanation on how to do this properly through javascript library, or through API call without running into CORS problems?
Your link to Google Maps Package is Node.js package (server side). That's why you have CORS issue.
If you're building a client-side application, take a look at the
Places SDK for Android, the Places SDK for iOS, and the Places
Library, Maps JavaScript API.
If you want to use it Google Maps on client side, you should use Maps JavaScript API
I have created an API using Swagger.
My customers will be able to make calls to my service like
https://theservice.com/data/items/category1/12345
This is fine and works ok.
However, I would like to have a page where they can see all available API calls, similar to how Swagger generates it on their SwaggerEditor app. For example by visiting https://theservice.com/index.html I would like them to see the API docs.
Is it possible (within Swagger) to do this on a live system (not just locally with swagger project edit which I already know)?
If yes, how?
It sounds like you're using the Swagger Editor to describe your API, then generating some scaffolding code using the built-in generator. From your tags, I assume this is node.js code. You'll need to add your own logic to the generated code to complete this API implementation (if you haven't already done so).
If this is correct, then the interactive Swagger-UI documentation you're looking for should be available in your generated API at /docs endpoint, relative to the base URL of your running service.
The generated node.js project includes the Swagger spec you created in the editor, and uses Swagger-Tools to do the runtime magic. Among other things, Swagger-Tools auto-wires your Swagger spec to the /docs endpoint, and manages routing of requests to the generated controllers, based on information provided in your Swagger spec.
Note that the /docs page will look and behave somewhat differently from the documentation widget you see in the Swagger editor. The one in your application uses Swagger-UI, which is the runtime component for documentation, with interactive sandbox testing. Swagger-Editor has its own built-in documentation UI, and this is not currently packaged for use outside of the Swagger-Editor.
If you've already implemented an API, independent of the Swagger editor and code generator, you can still generate node.js code to see how to incorporate Swagger-Tools into your existing API implementation. Or, as wing328 suggests, take a look at Swagger-UI to see how you can add your own documentation page.
I think what you're looking for is swagger-ui and here is an example: http://petstore.swagger.io/
As you can see, it not only lists out all the available API endpoints but also lets visitors (developers) to try it out directly in the web page.
I'm currently developing a Chrome extension and planning to publish it on Chrome market. I'm aware of open-source community benefits, however, do not want to share the source code and a bit worried about copyrights. Currently, the plan is to minify and obfuscate the source code before publishing. So the questions is:
Does Chrome Market accept extensions with minified and/or obfuscated source code?
Thanks in advance! :)
Any existing answers above have been rendered obsolete by the terms change on January 1st, 2019. This change was announced on October 1st, 2018.
In summary:
Google Allows minified code.
Google disallows obfuscated code.
The specific policy, available at https://developer.chrome.com/webstore/program_policies, is as follows:
Developers must not obfuscate code or conceal functionality of their
extension. This also applies to any external code or resource fetched
by the extension package. Minification is allowed, including the
following forms:
Removal of whitespace, newlines, code comments, and block delimiters
Shortening of variable and function names
Collapsing files together
2019 Update:
Google allows minified code, but not obfuscated one. See Brian's answer
Original answer:
Yes, you can use obfuscation tools (like jscrambler) before publishing your extension. I don't know if that may delay the publishing time, but I know for sure that are some published Chrome extensions with obfuscated/minified source code.
I, for instance, minify the code of my extension (LBTimer) with Google's Closure before publishing it.
It looks like they don't approve minified and obfuscated code. You can check thread on the Chromium Google Group, from April '16.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/1Jsoo9BPWuM
No, you cann't. This is email I received from Google Chrome Team: All
of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
You can get a more specific answer if you contact the Google Chrome team.
Update with own experience:
I wasn't able to submit a build obfuscated with this javascript-obfuscator (more specifically, gulp version in my case) They were complaining about "your code is suspicious" so I guess something triggered an alert in their system.
However uglyfy worked for that - I still had to figure out a way to rename all the prototype functions as uglify doesn't seem to do that (or at least I wasn't able to find a way to do that)
Original answer:
To sum up, it seems like chrome extensions are allowed to be minified and obfuscated.
For more details, keep reading.
First of all, there are two different terms - chrome extension and chrome app and different rules applies based on that. Chrome app has more strict requirements and it seems like mcastilloy2k's answer is suitable for chrome app (at least it looks like it is based on the available policies for both).
And regarding the below google's answer:
Avoid requesting or executing remotely hosted code (including by
referencing remote javascript files or executing code obtained by XHR
requests).
If it's for chrome extension and not for chrome app that seems strange as per the extension FAQ from google which explicitly states that extension is allowed to make external requests to execute custom API aka 'remotely hosted code':
Capabilities
Can extensions make cross-domain Ajax requests?
Yes. Extensions can make cross-domain requests. See this page for more
information.
Can extensions use 3rd party web services?
Yes. Extensions are capable of making cross-domain Ajax requests, so
they can call remote APIs directly. APIs that provide data in JSON
format are particularly easy to use.
Can extensions use OAuth?
Yes, there are extensions that use OAuth to access remote data APIs.
Most developers find it convenient to use a JavaScript OAuth library
in order to simplify the process of signing OAuth requests.
Another discussion in this google groups thread shows that rejection might not be connected with obfuscation at all:
Eventually, these are the things I needed to do to get my extension
passed (but I keep my fingers crossed in case some other validation
test still has to be performed):
I created a privacy policy and added a link to it on the Google Chrome developer dashboard.
I explained in more detail what my extension is doing. It seems that Google needs this to have a better understanding of the extension.
In the description I explicitly stated how the extension handles personal or sensitive user data.
Eventually that was enough to get the extension
pass the checks even with minified & obfuscated code (but remember I
keep my fingers crossed).
Moreover one can always go and check existing extensions out there, like Grammarly for example, who has obfuscated code (to some extent at least) and who uses external API.
How can I integrate Onedrive with Winjs. A search showed no result, but I found the dvlup challenge, for onedirve integration (not sepcific to Winjs).
Depends what you mean by WinJS. If only a web app, then use OneDrive exposed API straight away just like any Javascript API. OneDrive uses OAuth for logging in: https://dev.onedrive.com/auth/msa_oauth.htm
In WinJS case this means utilizing XHR and Promises. You can find some tips for OneDrive OAuth from Twitter OAuth from this post: Twitter OAuth with WinJS (They work in same way).
If for specific device, set right manifest rules and possibly need to download SDK for handling files. WinJS includes FileOpenPicker and FileSavePicker for files handling (Found from Windows.Storage.Pickers namespace): https://dev.onedrive.com/sdks.htm
so am developing an extension using crossrider and want to use native browser APIs after detecting which browser the extension is working from, am experiencing a bug that only the native APIs can solve it.
In general, you can use browser specific APIs for which the extension has permissions and use our appAPI.browser.name and appAPI.browser.version properties to differentiate between browsers.
However, if you are experiencing a specific problem with a Crossrider API method, please email support#crossrider.com with the details and we will be happy to assist you.
[Disclaimer: I am a Crossrider employee]