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!
Related
While pruning the number of sites that are allowed to send notifications to me, I discovered one allowed notification rule that surprised me: *://www.goko.com/*:
(This is found at chrome://settings/content/notifications )
How can I find out which of my Google Chrome Extensions is enforcing that I allow notifications from goko.com (without brute-force disabling/uninstalling them until I discover that the permission is gone)?
I'm creating a Chrome extension that modifies the gmail UI.
But when I authenticate (with chrome.identity.getAuthToken) in the Chrome extension, it defaults to using the user account that is signed into Chrome.
But I need data for a gmail account when I am on that gmail page.
I saw this answer, but I was wondering if there was any easier way?
I just went through the same process and I couldn't find an easier way.
You'll need to authenticate yourself.
We tried using the mechanism in that link but it requires putting the Client Secret in the Extension - very ugly.
In the end we request and refresh tokens externally through a hosted web page from our www site.
Although a hassle to set up once in place it works nicely and is worth the effort.
I'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.
I have a bit of a nagging problem here. At my current position, we have a Google Apps domain set up (for the sake of this question, it will be pennmanor.net) and I would like to determine a way to log in to Google Chrome (the web browser) and connect the Apps account to sync the settings.
I have found this article: Bug Report that describes the issue, which has been resolved. I have made sure that the options described in Comment 64 are correct, but still no sync. Other articles suggest that it is simply a matter of punching in the credentials and thats it.
We do have a custom SSO and Active Directory set up with the apps account, would this possibly be the cause of the problem?
Does anyone know what I might need to do to enable account Google Chrome to sync pennmanor.net account?
Are you setting user's Google password? Chrome Sync will not use the SSO password. If your users are stored in Active Directory, you can use the Google Apps Password Sync tool to sync passwords from AD to Google as they are changed:
http://support.google.com/a/bin/answer.py?hl=en&answer=2611859
I started reading Google Chrome's documentation, and liked it's approach of using HTML and Javascript to create extensions. Reading this tutorial about Local Storage made me think about a lot of different uses.
I want to develop an extension to help me with corporate systems. It's very specific, and it's only going to be used inside a company.
This extension would do some activities to this corporate system, using javascript DOM, with just one click on Google's Chrome toolbar. To work with just one click, the extension needs to store a password in Chrome: so if you restart your system, you don't need to enter it again.
How do I do that? Persist a password in a Google Chrome extension to login to another system? I don't want to store it in "plain text", I would like to at least use some kind of encryption (maybe a Google Chrome API with this resource).
Is it possible? How do I persist this data with Google Chrome's extensions structure (best way)?
You could encrypt and store a user’s password with localStorage (or the Web SQL Database API). But not very securely. Anyone who gained access to the user’s computer could retrieve the ciphertext, pluck the encryption algorithm out of your extension source, and determine the plaintext password.
If feasible, here are a couple more bulletproof solutions:
Piggyback on the user logging into a web interface. For an example, see the Google Mail Checker.
Connect to the services through OAuth (or a similar authorization scheme). For an example, see the Google Wave Notifier.