I have two google calendars that I am trying to add events to programmatically through HTTP requests. I happen to be using iOS HTTP library, but I imaging that's largely irrelevant.
Both http requests are coming back as successes, but one calendar is declining the invitation.
It appears to me that they are both set up the same way, although I don't have admin access to them.
Is this more likely a calendar configuration problem that I can't see or is this an HTTP request problem?
Does anyone know the proper configuration settings for the calendars?
Edit: I asked for and received admin access to a pair of calendars, one that works one that does not. Both calendars have the "See all event details" preference selected
Related
I'm getting invalid_grant error when creating a draft.
Scopes I requested:
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/contacts.readonly
https://www.google.com/m8/feeds/
https://mail.google.com/
https://www.googleapis.com/auth/gmail.settings.basic
https://www.googleapis.com/auth/calendar
I use python library to interact with Gmail API (
The main problem is that this sometimes works as expected, sometimes it doesn't work and I don't know why.
My code look like the one from example here: https://developers.google.com/gmail/api/v1/reference/users/drafts/create
Based from this thread, the possible problems that cause invalid_grant errors are if your server's clock is out of sync with NTP and/or you've exceeded the refresh token limit. This page also suggested to make sure that you specify access_type=offline in your request.
Here's a related SO post for a checklist of potential causes for the problems:
Server clock/time is out of sync
Not authorized for offline access
Throttled by Google
Using expired refresh tokens
User has been inactive for 6 months
Use service worker email instead of client ID
Too many access tokens in short time
Client SDK might be outdated
Incorrect/incomplete refresh token
User has actively revoked access to our app
User has reset/recovered their Google password
Hope this helps!
I'm currently trying to configure a route we can call it sub.domain.com/route and on domain.com I have a angular app that sends a post to that end point.
What I'm trying to figure out is do I have to add in CORS to sub.domain.com/route to only allow post requests from domain.com? Or do I have to create a tokening system on domain.comto prevent someone from being able to send curl requests and use that route or to use that route on their website/app without my consent?
I'm trying to limit people who can access that route to only people who are physically on domain.com using my application and clicking the button that sends the post request.
You will need to use some other form of authentication (e.g., tokening, password, etc...) as CORS will only affect whether or not resources such as scripts, served to a user's browser from one domain will be able to interact with services hosted on another. This will do nothing to help against CURL requests, proxies, etc...
I originally wrote an REST API to work with a previously written mobile app. The mobile programmer requested from me to generate an auth_token on login that he will pass as a header on each request that needed authentication. This API runs at api.example.com.
Later on, I was commissioned to write an AngularJS app that communicates with this API, so I had to use Access-Control-Allow headers on the backend for OPTIONS requests to be CORS compatible CORS so my browser allows the connection (looks like iOS does not look for this headers). This app runs at one.example.com.
Now, I have to write a second AngularJS app that will run at two.example.com and there's a third being planned for the near future at three.example.com.
My problem is that my Access-Control-Allow-Origin header looks like this:
Access-Control-Allow-Origin: http://one.example.com:80
* is not allowed, nor I'm able to set this header to more than one origin. So as far as I can see I have two solutions:
Implement token-based authentication in parallel to the current cookie-based one. I'm thinking on this. This will of course take some time I'm willing to save.
Send the requester a header or param to the API endpoint identifying the app on the OPTIONS request and server-side, produce the CORS headers accordingly. I don't even know if it's possible and this looks nasty for even thinking it.
Any better ideas?
If they have the same origin, example the same domain (example.com) or the same subdomain (1.ex.example.com and 2.ex.example.com) they can share the same cookie. Because cookie is based on the domain itself.
I have a mirror-api application i'm writing that takes notes, pictures and video from the users timeline and stores them. For some reason every note and picture I take and send to a contact i inserted through mirror has "Failed to Send" posted on the timeline card in glass. The app however still receives the timeline item. Anyone else having this issue?
You need to setup the timeline subscription (https://developers.google.com/glass/v1/reference/subscriptions/insert) with "UPDATE" item included in the "operation" list.
Mirror API will sending POST queries with the shared card info to your callbackURL endpoint. Accordingly your service should return HTTP Status 200 in response.
The endpoint should have HTTPS connection. To solve this - use ngrok (https://ngrok.com/) if you're developing on localhost or Google's subscription proxy (just google it, i can post more than 2 links now)
I'm trying to implement a simple interceptor that allows me to display a message along the lines of "cannot contact the server" in my Angular app. However as the API is on a different host I'm dealing with CORS pre-flight OPTIONS requests.
I've found that if the API is unavailable Chrome dev tools shows a 503 on the OPTIONS request but Angular's $http interceptor catches a 404 response to the subsequent GET request. I believe this is because the OPTIONS response did not contain the required CORS headers so the GET is actually never performed.
Is is possible to intercept the OPTIONS response? If all I see is a 404 I can't distinguish "server down" from "no such resource".
You can't intercept this request by design - the browser is "checking up" on you, making sure YOU should be allowed to make the request.
We've used three solutions to work around this:
If the problem is that you're using a development environment like NodeJS, and your domain names aren't matching (that is, if you normally wouldn't need to deal with this in Production) you can use a proxy. The https://github.com/substack/bouncyBounceJS NodeJS Module is an easy to use option. Then your Web service request domain will match the domain your page is on, and the check won't be triggered. (You can also use tricks like this in Production, although it can be easily abused!)
Also for temporary use, you can use something like Fiddler or Charles to manipulate the request by faking the required headers, or tell your browser not to check them (--disable-web-security in Chrome).
If you have this problem in Production, you either need to legitimately fix it (adjust the Web service handler to add the required headers - there are only two), or find a way to make the request in a way that doesn't trigger the check. For instance, if you control both the source and target domains, you can put a script on the target that makes the requests to itself. Run this in an IFRAME, invisibly. Then you can use things like postMessage() to communicate back and forth. Large services like Facebook use "XHR bridges" like this for the same reason.