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.
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 have a google form that I am having pushed out through a Kiosk App and that google form is going to be used for the foreseeable future. Since I am not a Network Engineer or Systems Administrator in my network, the only way of getting the webview element in my App to display the Google form is to hard code it's URL because I have nowhere from which to dynamically update the URL in my App at the moment.
I am also not the Chrome Administrator and because of this I need to send my packaged Kiosk App off site to have it pushed out to my building's Chromebooks which means that for every update that I do, I need to re-package it and have the Chrome guy update it manually.
Since I and many others would prefer to not perform the task noted above on a frequent basis, I am trying to find out how long the Google Form's url will last and/or how often we can expect it to change if it does ever change.
Surely if you have any concerns over the link changing, you can just set up a redirect from a domain you control.
That way even if the kiosk form gets upgraded from Google to something else, you can just change your redirect without recompiling and redistributing your application.
Here My question is that i want to create one html5 based cross platform mobile application.
In which i want to read my gmail mail data and want to display it in my application page.
Here i don't want to send any mail using this app i just want to display the mail of my gmail account.I searched about it on google but i did not get any result for it.
if we make something like it then give me some information about it how to read data from gmail mail.If we can't do then please give me some reason for it or helpful links.
So if anyone have any idea about it then please help me.
Thanks in advance !..
Pure HTML 5 Alone
No. As the other answers point out, Gmail does not provide a RESTfull API that would be accessible to a HTML mobile app. However, Gmail does provide the standard IMAP and SMTP APIs. You can read all about integrating GMail features within apps here: https://developers.google.com/gmail/.
Pure HTML 5 With Middleware
Using pure mobile HTML5 cross platform code - you will not be able to make use of these APIs. However, you could write a server to act as a middleware between GMail and your pure HTML 5 application. The server could do all the interaction needed with Gmail, and your application could interface with the server. I'm not recommending this because you could be opening up your user's Gmail to many security flaws, and it would be a lot of extra work on top of the HTML5 app - but it is possible.
Mobile Chrome App
Although this is not pure HTML5 - Chrome Apps allow TCP socket connections. Having direct TCP connections would allow you to write - or find an existing - IMAP client to read email. Next, you could use Mobile Chrome Apps to put your chrome app on IOS and Android. This is not pure HTML5 and is not 100% cross platform (windows phone, etc), but you app would be able to directly talk to Gmail.
Platform Specific Apps
Of course the final option is to write platform-specific apps that can directly interface with IMAP & SMTP. This option does go directly against your requirements in the question, but I felt like it should be included to be a comprehensive answer.
Sorry, but you cannot create such Html5 based cross platform mobile app
(which seems like an email client, though used for reading purpose only). Google hasn't provided any Rest API through which we can access our gmail accounts. Link provided by #tnt, itself says in its last line:
Please keep in mind that Gmail messages will appear in your aggregator only if there are unread messages in your inbox.
You can even check the list of APIs provided by google: APIs Explorer
You can add a middleware (server) like:
Your application <--> Your server <--> Gmail
For this, you should have a server.
Create RESTful web services (using, WCF, for example) that will do your job of bring mails to you. Publish it. And, you can, then, use those service urls in your html pages. This the way you can achieve, what you want (making cross platform mail clients, I guess)..
My suggestion is to go with phonegap.I used it in which u can create apps in HTML5.Also since for gmail use gmail apis in html5.
The following link is for phonegap
http://phonegap.com/
Which kind of cookie is required to work with webContentLink? I noticed when I'm logged in to Gmail only, i get 403 error. When I open Google Drive too in on other tab and check some files, then my webContentLinks starts to work. Is this the way it should work or did I missed something? Once it was sufficient to be logged in only in Gmail...
(I have a very simple web application, that shows some links to files I shared with my friends in Google Drive. I don't want to use further authentication, but public is also not an option. It was very convenient to have accessible links when their Gmail is opened.)
Could a chrome extension be made that maintains a bitcoin wallet while also making it easy for web stores to integrate a one-click purchase experience.
Suppose a button on a webpage is clicked. Is it possible for that to trigger a function call to the chrome extension to send bitcoins?
Obviously letting webpages unlimited access to chrome extensions would never have been designed. But is there some way to make this work securely?
Chrome extensions can insert arbitrary code into web pages (content scripts).
Content scripts are JavaScript files that run in the context of web
pages. By using the standard Document Object Model (DOM), they can
read details of the web pages the browser visits, or make changes to
them.
This code can communicate with the original web page via the DOM and with the rest of the extension via message passing.
In theory, this should suffice. But make it secure, please.
Multibit provides an external application solution
Clicking on a "bitcoin:" protocol URI in Chrome (or any other browser) will transfer the URI over to MultiBit (v0.3+), starting the application if necessary. This approach removes the need for private keys to be held (and potentially shared) within the browser.
This is very dangerous because a single security hole in Chrome could allow any website to empty your wallet.
First, any payment have to be confirmed with the wallet password. But, as that password is typed inside Chrome itself, it might be possible for an attacker to read that password.
In fact, there are so many security issues to solve that I think it's better to let the bitcoin client do that job.
What should be done is a way for any software to ask the bitcoin client for a transaction. The first idea that comes to mind is using DBus.
That way, the Chrome extension would only have to transform any bitcoin address by a button which calls a DBus method.
The blockchain.info Bitcoin Wallet provides some support for this
by using navigator.registerProtocolHandler and Bitcoin URI's. Unfortunately it only works in firefox at present.