I am using InboxSDK and gmail API on PHP to build a chrome extension.
Everything is flowing quite okay so far, but I am facing a big obstacle.
What is my purpose?:
Via InboxSDK, I want to handle when a user attaches files.
Send all the information to my server.
Attach the files and send the mail via Gmail API from the server.
Where am I?:
I already authorize the user with OAuth2.0 and keep the tokens and also I am already able to send the e-mails written in Gmail Web via server Gmail API.
I do not know how to move on with handling the files.
How may I proceed?
Also, if there is any alternative way to achieve this without InboxSDK I am happy to hear.
Thank you.
It is not possible as mentioned.
But there is a workaround.
Create a draft via InboxSDK.
Fetch the draft via gmail API.
Send the created draft, which already contains the attached files.
Related
I'm trying to share my API (with a custom domain) with the customer( service consumer role), but this API is not listed in the API library. When he tries to open API using the link to generate API key he gots errors. The same problem I have when I try to generate API key for customers. I'm using endpoints frameworks for the GAE standard environment. Image
This one looks more like a problem with the Cloud console or the Cloud APIs, I'd better address the issue at a Public Issue Tracker (PIT), you can open one in here, and preferably add a relevant HAR file that should contain some additional information of the response message.
This will help to correctly address any ongoing service issue.
I have taken a look around the internet and all the solutions emphasize using Express and Node Js API in place to able to send an email. I would love to see any suggestions on how to best go about it because I don't have a backend in place. Thank you.
You're going to need some sort of backend otherwise the API-Key will be exposed.
From the SendGrid documentation:
When you have a browser-only application that reaches out to APIs, the API key has to be embedded in the application. Anyone with access to a browser-only application can access all of the Javascript source code, including your API keys.
Making your API key publicly accessible could result in anyone authenticating API calls with your API key — this is a significant security concern both for you and SendGrid.
You could use a serverless AWS lambda function or google function which would be a "backend" but without having to support the infrastructure / use a big framework.
I am work on a web application as an interface with Google Cloud Storage(GCS).
I am using a backend service to retrieve the list of files I stored on GCS and their URL with the JSON API and return that to my web application. However, I was not really able to load the files through those URL, which always came back with 403 forbidden.
I am not sure how GCS authentication work behind the scene and whether it is possible to directly grant access to web application. I am not sure how could I attach application authentication information via http request. What I know is I can do that via the backend service but for the reason of simplicity I wonder if it is possible to get around with that. One of the thing I tried is adding the web application domain(which will be sent via referrer in http request) into ACL to that bucket, which doesn't work at all.
And thanks to what #Brandon pointed out below. I am ok to grant anyone whoever have access to the application to view the content of the GCS since it is an internal app and I have already checked their authentication when I first serve the web application.
====
Solution
I ended up using the signedUrl that expire in 5 minutes and I highly recommend interact with gcs using gcloud (Their python document is really good). Thanks again for the thorough answer!
You have a user on a web browser who wants to download an object that only your application's service account has read access for. You have a few options:
Expand access: make these object publicly readable. Probably not the best choice if this info is sensitive, but if it's not, this is the easiest solution.
Give your app's credentials to the user so that they can authenticate as your app. This is a REALLY bad idea, and I probably shouldn't even list it here.
When a user wants to download a file, have them ask your app for it, and then have your app fetch the file and stream its contents to the user. This is the easiest solution for the client-side code, but it makes your app responsible for streaming file contents, which isn't really great.
When a user wants to download a file, have them ask your app for permission, and reply to them with some sort of token they can use to fetch the data directly from GCS.
#4 is what you want. Your users will ask your app for a file, your app will decide whether they are allowed to access that file via whatever you're doing (passwords? IP checks? Cookies? Whatever.) Then, your app will respond with a URL the user can use to fetch the file directly from GCS.
This URL is called a "signed URL." Your app uses its own private key to add a signature to a URL that indicates which object may be downloaded by the bearer and for long the URL is valid. The procedure for signing URLs is somewhat tricky, but fortunately the gcloud storage libraries have helper functions that can generate them.
I've set up oauth and am properly retrieving an access token.
Here is the response I get from hitting
https://www.google.com/accounts/AuthSubTokenInfo?access_token=<token>
parsed_response="Target=645428735890.apps.googleusercontent.com\nSecure=false\nScope=https://www.googleapis.com/auth/userinfo.profile\nScope2=https://www.googleapis.com/auth/userinfo.email\nScope3=https://www.googleapis.com/auth/glass.timeline\nScope4=https://www.googleapis.com/auth/glass.location\n"
which I believe properly shows that I have requested the correct permissions.
A call to
https://www.googleapis.com/mirror/v1/timeline?access_token=<token>
yields:
"errors"=>[{"domain"=>"usageLimits", "reason"=>"accessNotConfigured", "message"=>"Access Not Configured"}]
Having trouble figuring out what this means. I don't have an actual piece of glass hardware. The docs make it seem like this access token would allow me to make any requests to the mirror api.
Is there an additional setup or permission I need to ask for that I missed? On the application side? Is this related to my google account and having not set up glass?
EDIT:
Okay, from the authorization docs:
Select the Services tab in your API project, and enable the Google Mirror API.
However, I'm not seeing Google Mirror API listed on the services tab?
The Mirror API is currently in developer preview and access is limited to I/O Explorers who have received their Glass device. You can subscribed to this issue on our issue tracker to get updates on when the Mirror API will be public.
Google App Engine currently limits you to 2,000 emails per day (for free) via their API.
I am trying to find a definitive answer if it is possible to use a third-party system if you need to send more. I know that they disallow raw sockets, so I would assume that there might be trouble with this approach... but surely I'm not the first to see it.
Worst case, I can build a simple offsite web service that my GAE can call... but I'd much rather just be able to send directly through an SMTP server.
Thanks!
Nope.
You're correct: you cannot make raw socket requests, nor any other direct outbound requests except through the urlfetch API. To talk to an external SMTP server, you would need to use a webservice as a proxy.
We use the Postmark mail outsourcing service via the hutools.postmark API. Since the communication is HTTP based, it works like a charm on Google AppEngine. This might be an option for you, although it is also a for-pay service. We use it to get arround GAEs sender restrictions.
I've successfully used third party providers for email services with Google App Engine. I've used both SendGrid and MailGun using their HTTP-API.