As stated in the document, the syncToken can become invalid, What is the syncToken expiration? Is there any time limitation for SyncToken?
There doesn't seem to be any public documentation disclosing the expiration timeframe. The people.connections.list API also uses a syncToken and it expires 7 days after a full sync. You could use that as a reference, though the Calendar token may behave differently.
Sometimes when developer documentation is intentionally vague about details like these is because the limits are confidential to prevent abuse. Either way you should follow the documentation's advice to react to the token expiration and request a new full sync when needed, since this is necessary whether or not you know the token lifetime. You can track a few tokens to see when they expire and reach your own conclusions.
It could also be an oversight in the documentation, so I'd also recommend clicking the "Send Feedback" button at the bottom of the page to request an update. I've done so myself so hopefully it's something that they can publish.
Related
I was testing functionality on a website that I'm developing that allows the user to sign in using their Google account. I filled in the "OAuth consent screen" in the Google Developer's Console, including all of the URLs to allow Google to redirect a user back to my website with the necessary OpenID information. Everything works, but I used test URLs on the "OAuth consent screen". Afterwards, I made the very costly mistake of clicking the button at the bottom of the screen labeled Submit for verification. I should have clicked the button labeled Save. The URLs on my OAuth consent screen all have internal hostnames, so they're not accessible from the Internet. Is there any way that I can cancel the request to Google for verification? The page is currently frozen, and it won't let me change any of the URLs until I inevitably fail the verification process. There is also a message that states that verification may take up to 4-6 weeks, which is a long time to wait for something with a known outcome...
I know this may not be the right forum for this question. However, Google's own support page links to StackOverflow, and I'm sure web developers must encounter this problem quite frequently. I tried looking on Google's FAQ pages, but didn't see anything about canceling the verification process. It's quite possible that I missed something....
Edit I've received an e-mail from the Google Cloud Platform notifying me that my request to have my app verified has been denied. This makes sense, since I completed the Consent form with incorrect test URLs. However, the Save button on the OAuth consent screen is still disabled. The screen appears to be in the verification process. Perhaps this is the intended workflow for the screen. At any rate, the original request for verification was denied within a day or two, which was quite fast considering the 4-6 weeks that Google allows for the process. If anyone can confirm or deny that this is the intended behavior of the OAuth consent screen, I would be happy to mark their answer as correct...
At this point, I'm inclined to believe that this is the intended behavior of the OAuth consent screen. 3 days after the verification request has been declined, the message Your consent screen is being verified. This may take up to several weeks. Your last approved consent screen is still in use. is still being displayed. I now believe that further changes to the screen, such as updating the URLs, will require the verification process to be restarted, since the Save button remains disabled.
I built a Chrome Extension using the Google Slides API ~8 months ago, with users having to sign in with the OAuth consent screen as to be able to use the extension. The extension has over a thousand users, and for the past weeks I've had reports of people seeing an error that says "Sign in with Google temporarily disabled for this app".
I checked and indeed the OAuth page was still "being verified", although it still said it would only take a few days / several weeks. I'm not using any sensitive scopes either, so it all seems very odd. If the app didn't meet the criteria I would have been rejected, but that doesn't seem to be the case.
So my question is, how can I get it verified, or if anything rejected so that I can make a new submission? I looked all over the place and I haven't found a way to get it unstuck. I'm pretty sure 8 months for verification isn't normal whatsoever.
Google seems to manually validate each OAuth screen. That's a long (and costly process), but to my experience, it generally takes 24 hours if you don't use any sensitive/restrictive scopes. As it's your case apparently, I presume your submission has probably being lost somewhere.
My recommendations:
Check in the Google Cloud Console the status of your OAuth Screen. After logged in Google Cloud console, click on the hamburger icon and select "APIs & Services" > "OAuth consent screen". At the top of the page you will see the status. If it's something like "pending verification", go to step 2. Otherwise, make sure the form is completed and submit it to verification again.
Search in your emails if you have been contacted by "api-oauth-dev-verification-reply [at] google [dot] com" (the address might slightly change as they use a ticketing solution). Maybe they tried to contact you but the email went to spam?
Get in touch with the OAuth team by emailing "api-oauth-dev-verification-reply [at] google [dot] com". Make sure to add your
Google Project number in your email, so they will be able to check
what's wrong.
Disclaimer: I don't work at Google. But I'm bit familiar with that process now :)
With a simple java program, I send GET requests using YouTube Data API specifically videos.list, in order to get the public metadata of a video and store it as .json files.
For my universities research, we have to do this with all available YouTube video IDs provided in the Youtube-8M Database.
Therefore, I would like to know if there is a way to extend the available quota for requests (I already know about the billing option, but I am a student and my university is small).
I have read the YouTube API terms, which states that only one project per client may be used to send such requests with the necessary API Key.
If I understand it correctly, even my simple java code is such a client.
In some other Stack Overflow questions about extending ones daily quota with API Keys, some suggested creating multiple accounts or projects.
Is this a legal option or not? Or is there another possibility to get a higher quota for simple requests used in research like I do right now?
If you go to the Google Developer console where you enabled the YouTube API. the second tab is called quota
Click the pencil next to which ever quota it is that you are blowing out. A new window will pop up with a link called apply for higher quota.
Fill out the form to apply. To my knowledge you do not have to pay for additional YouTube quota but it can take time to get approved. Make sure you comply with everything on the form.
I have never heard of the one project per client term. Technically you can run your application using different API Keys it should work fine. Technically there is nothing wrong with creating additional projects on Google Developer console. You don't need to go as far as creating another Google account.
I'd like to be able to use site comment features on sites that use the Facebook Comments Social Plugin. When I'm logged in to Facebook, I see my profile picture next to the comment box and I can see other comments if any have been made.
When I make a comment, it shows up right away, but doesn't seem to register publicly. If I log out of Facebook, my comment disappears.
More information is coming to light, as well (added March 26, 2013). There are several people affected by this bug who have attempted to get help on Facebook with the issue, so far withouth success.
After I added a fake app to my Facebook developer profile, I was able to post a bug to Facebook, however it has been since closed without being resolved.
Since Facebook comments are now being used as the exclusive online interaction method by several news media outlets, this problem means that some Facebook users are disempowered from being part of the community discussion of news of the day. Does Facebook wish for that to be?
Over time and in conversations with many people, I've learned more about this issue. From the perspective of websites which host the comments plugin, I've learned that comments from certain users, not on the site banned list, are automatically queued by Facebook for moderation.
Also, I recently ran across an answer here on Stack Overflow that indicates that "Fresh" Facebook accounts are designed to be held for moderation in the Comments Plugin, presumably to prevent someone who has just created a Facebook account from using the new account to post spam comments on other websites. I wouldn't consider my account "Fresh" but it is still less than a year old. In the Facebook response which closes the website report they state "The affected user you added to the report has no friends and we suspect the user to be fake and request moderation. This is by design." While it is understandable that Facebook wants to limit the potential for fake users to post in these comments, this metric apparently also snares legitimate users.
Q.Mark, I strongly recommend that site owners not use the Facebook Social Plugin to support commenting on their sites, unless they want to annoy visitors.
Facebook uses an Orwellian blacklist/censorship model which prevents many people from posting comments. Users get no explanation for why their comments won't post. Rather, it's made to look like a malfunction of the web site, and it is only apparent after the users waste their time composing a comment.
There's discussion of the problem here (among many other places):
https://www.facebook.com/help/community/question/?id=10200248881692914
(Copy saved here:
http://burtonsys.com/Why_cant_I_post_comments_on_sites_that_have_the_facebook_social_plugin.pdf )
A FB "Like" button is useful, but site owners should not use Facebook to support comments. Use Disqus, or LiveFyre, or anything else besides Facebook.
(I realize this doesn't solve your problem, sorry! But perhaps if enough site owners dump Facebook for comments then Facebook will stop what they're doing.)
I was able to post a comment, but it didn't show up on my profile even though share on fb was enabled.
To submit a bug, all you need to do is go to developers.facebook.com/bugs and start typing something in the search field, and you'll see an option to create a bug report from there.
I'm trying to use the OAuthConsumer library for Cocoa to connect to users' LinkedIn accounts.
Following the steps provided by the original author of OAuthConsumer, I set up the request token, and point a WebView at the resulting URL.
Now, with other services that I've used OAuthConsumer for (Twitter, Facebook, etc.), this part works fine. The user logs in, authenticates the app, and then my code kills off the WebView and trades in the newly authorized request token for an access token.
However, with LinkedIn, I'm getting the error "We were unable to find the authorization token". No more information; no error codes. Just a neatly rendered webpage full of useless.
So, I ultimately have no idea where to even beging debugging this issue, or whether or not it's a problem with my code at all. The few minor leads I've been able to find on LinkedIn's forums state that my "timestamp may be off" (though, not according to Epoch Converter), and I should check the "timestamp in the response". Seems like a red herring to me.
Edit:
Charles Session
So, it turns out the parameter for returning the request token is "oauth_token", not "token", as I was using.
Now, this would ordinarily just be a commentary on the inconsistencies of OAuth implementation, and my oversight. However, I'm a bit concerned because there were several instances (mostly using a browser) where using the wrong parameter in the return query would work: a serious inconsistency, and potentially severe oversight on LinkedIn's part.
At any rate, it works now.