I am currently researching Google+ REST API to post to a user's stream.
The basic requirements are:
The post should be created without user's review using server side request (user should give his permission to post on his behalf in the future).
The post must be visible to all user's friends.
As i understand from reading the documentation, posting to the stream without actually getting permission in creation time from the user is impossible, however, creating 'moments' doesn't require permission upon-posting, so the user should give his permission when authorizing the app.
Since i didn't find anything that explains how can a moment be created to be visible to all user's friends - can someone who is familiar with this API explain how visibility of a moment is being determined and on which step? reference to an API documentation would be good as well, but i didn't find any.
Thanks
The moment methods do not write directly to a user's Google+ stream. They instead write to a user's profile, and are not necessarily viewable by others depending on the user's preferred sharing settings.
Manage app activities in Google
During authorization the user chooses who their activity is visible to.
Once authorized a user should be able to see their own activities on Google+ and you can view other people's activities by clicking on an app from their profile about page.
Related
I generate a auth link like:
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?access_type=offline&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar.events&prompt=consent&response_type=code&client_id=xxx&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fapplication%2Fsettings%2Fgcal&flowName=GeneralOAuthFlow
As you can see I call for the authorization as defined in the documentation here https://developers.google.com/calendar/api/guides/auth however, when I go to auth this is what I am presented with: and I thought this might be some new security thing from google but then I look at connecting to other sites and the account works just fine there.
This application is also fully verified for the consent screen.
While doing some comparison between my calls and other site's I notice that mine have /v2/ in the path while others do not. I have tried multiple individual google accounts with same result, but I always get a v2 redirect.
Anyone here know why this happens with v3 accounts and how I can solve it?
Unfortunately, this is the new default behaviour
It is realted to the new policy of More granular Google Account permissions with Google OAuth and APIs
It is being gradually introduced and is not related to either v2 or v3 accounts are being used but rather will eventually implemented for all accounts
Should the user not grant you all the scopes necessary for your Addon to run - you will need to handle it programmatically checking which scopes have been granted and requesting additional scopes if required
Best practive would be to make it very clear to your users PRIOR to the app installation that checking all checkboxes is crucial for the correct functionality of the app.
There is a very good stackoverflow post that explains the new change more in detail and includes many useful references.
I received this message for the second time and i still dont understand why. Can someone help me?
Action required: Critical problem with your Google Cloud/API project
Youtube API (id: tonal-topic-123301)
Dear Developer, We have recently
detected that your Google Cloud/API project Youtube API (id:
tonal-topic-123301) is using a Google product name as the project name
shown to users on the OAuth consent screen, which violates the Google
API Services: User Data Policy. You can fix the problem by revising
the project name and other relevant content so that the OAuth consent
screen shown to users accurately reflects the identity of your
application. To revise the project name visible to users, please take
the following steps:
Please review the Google API Services: User Data Policy, specifically
the following section- "Do not make false or misleading statements
about any entities that have allegedly authorized or managed your
application. You must accurately represent the company, organization,
or other authority that manages your application. Making false
representations about client credentials to Google or Google users is
grounds for suspension."
Sign in to the Google Cloud Platform Console.
Select your project.
On the Home Page Dashboard, select Go to APIs overview under APIs.
In API manager, select Credentials on the left bar, then select OAuth
consent screen. Change the name in the field under Product name shown
to users and then click on Save. We will suspend your Cloud project in
3 days unless you correct the problem. Please submit an appeal if you
have any questions. Please note that you should be logged in as the
project owner to access the appeals page. For more help on submitting
an appeal or to learn more about the process check the Policy
Violation FAQ. Please take a moment to review the Google API Services:
User Data Policy, the Google API Terms of Service, the Google Cloud
Terms of Service and the applicable Terms of Service for the specific
Google API you are using so that you do not violate our terms and
policies in the future.
This is obviously a naming issue regarding something in the google product range.
You Should be able to re-name your project to solve this.
If not, try a Google forum or help pages.
The problem you are having is that Google does not allow you to use a Google product name as the name of your in your application. Users can become confused and assume your third party application was created by them.
How to fix it:
Go to Google Developer console find the credentials screen. Click on the Oauth consent screen tab at the top rename your application.
Note: If you don't do this google is going to shut down your application they are very picky about this.
I'm making an application that requires access to the shared/room-resource calendars in an Office 365 instance, using non-admin accounts. I've registered an app (in the Microsoft Application Registration Portal) using the V2 endpoint and Auth Code Grant. This successfully allows me to log in, and gives me a functional token with the Calendars.ReadWrite.Shared scope. With this token, I can retrieve my own calendars, and calendars that have been explicitly shared with me (and therefore added to my list of calendars). All of this is doable with just the normal Calendars.ReadWrite scope.
However, I get errors when requesting access to any other shared calendars, like the room calendars. Here's an example. If I make a GET call to https://graph.microsoft.com/beta/users/my-own-email#business.com/calendars it successfully returns a list of my calendars. If I make a GET call to https://graph.microsoft.com/beta/users/meetingroom1.4#business.com/calendars I get a 404 (Not Found) Error. The same error occurs for any other user, not just meeting rooms. Note that I can see these calendars when I'm logged into Office 365 online with the same account.
A different error occurs if I ask for events not calendars. If I make a GET call to https://graph.microsoft.com/beta/users/meetingroom1.4#business.com/events, I get a 500 (Internal Server) Error.
I've checked all the other threads I can find on the issue, and this one from November How to access shared calendars from Office REST API? says there's some kind of blocking issue on Microsoft's end. It's using the Office REST API rather than Graph, but on the back-end the APIs call the same stuff. Is this issue still about? Alternatively, am I missing some further permissions? I tried adding quite a few different permissions on top of Calendars.ReadWrite.Shared, but none of them fixed it. Is there a correct combination?
Thanks so much for any help, and let me know if any other info would be useful for diagnosis.
So if anyone else happens to be interested in this, I figured out a way to access room resource calendars without using the Calendars.ReadWrite.Shared permission. This allows you to use just the Calendars.ReadWrite permission to access the room resources, by moving them into the list of calendars of the email you're authenticating with. However, it will only work for specific accounts that you share the calendars with, so won't be usable in apps that have to work for any account. This is good enough for my use-case, but may not be for yours.
First, find or make an account that is a delegate to, and has full access to, the room resource calendar you want to use. On that account click 'Open another mailbox' in the dropdown list under your profile image.
Open another mailbox location
In the pop-up that follows, put in the email address of the room resource calendar that you want to use.
Then, on the new page that opens (which should be the Office account of the room resource calendar):
Navigate to the calendar page
Click 'Share'
Share the default calendar with the account you plan to authenticate with.
Then log into that 'authentication' account, check its email for the notification of the shared calendar, and click 'accept'. What this will do is move the calendar into the authenticated account's list of calendars, meaning you can access it with just a call to the https://graph.microsoft.com/v1.0/me/calendars endpoint. You'll have to repeat it for every calendar you want to be able to access, sadly.
I recently noticed the addition of a "Session" object in Parse dashboard. Now, from what I understand, a session uniquely identifies a user to the server. So why would we need such a Session? For the session token? We already have a currentInstallation... so I don't really see the point. Can someone explain and provide a scenario where I would use the "Session" object. Right now they just annoy me by their presence because they take up potential space on the Parse server and I would like to go delete them all but want to make sure that isn't stupid.
The sessions are used by parse to deal with the users (is the user logged?, on which devices?, etc.), and are available as a class as you may want to manipulate them. By deleting the sessions you would automatically logout all your users, so it's a pretty bad idea.
You don't have to use or touch anything about this class, but here are few examples of why it can be useful:
[...] If a user contacts you about his or her account being compromised in your app, you can use the Data Browser, REST API, or Cloud Code to forcefully revoke user sessions using the Master Key. These new APIs also allow you build a “session manager” UI screen where your app’s users can see a list of all devices they’ve logged in with, and optionally log out of other devices. [...]
You can read more about the Sessions on their blog post.
I'm developing a Rails app, which contains importing of profile information from LinkedIn to a Rails DB.
It works fine a lot of the time, but over the last 2 weeks it suddenly stopped working...
Default Application Permissions on LinkedIn is only r_fullprofile
I use linkedin gem as a wrapper
Fields to import - positions, educations, summary, languages, picture-url
Error, which I see in PROD logs:
LinkedIn connect failed: Scope NOT_AUTHORIZED : r_fullprofile
.rvm/gems/ruby-2.1.2/gems/oauth-0.4.7/lib/oauth/consumer.rb:178:in `request'
.rvm/gems/ruby-2.1.2/gems/oauth-0.4.7/lib/oauth/consumer.rb:194:in `token_request'
.rvm/gems/ruby-2.1.2/gems/oauth-0.4.7/lib/oauth/consumer.rb:136:in `get_request_token'
.rvm/gems/ruby-2.1.2/gems/linkedin-0.4.3/lib/linked_in/helpers/authorization.rb:22:in `request_token'
As I see in debug, for some reason request token and secret are nil,
so I decide that the API to authorize client with my linkedin-app does not work.
ALso, I found an answer on stackoverflow that some API rules were changed some time ago:
After May 12th, 2015, apps will no longer be able to request this
member permission without being specifically reviewed by LinkedIn for
compliance with the Apply with LinkedIn use case
(https://developer.linkedin.com/docs/apply-with-linkedin) or some
other partnership program membership which grants access to that
permissions.
But, does some analog of r_fullprofile permisson exists now, which give an access to get all profile information from linkedin?
Here is what I found in Developer Program Transition Guide:
Access to the r_fullprofile member permission now requires explicit approval from LinkedIn. Additionally, the focus of this permission has changed to become much more specific. Going forward, data received from the Profile API using the r_fullprofile permission can only be used to complement your company's careers pages, as described further on the Apply with LinkedIn page.
If you are already using member data provided by r_fullprofile and you believe your application meets new useage criteria, you will still be required to apply for permission on the Apply with LinkedIn page to maintain your application's ability to use the r_fullprofile member permission.
Here is a link for Apply with LinkedIn if you need it:
https://help.linkedin.com/app/ask/path/api-dvr
I have asked for restoring API-access from my application,
hope that LinkedIn support help me.
Use Apply with LinkedIn to:
Round out your knowledge about a candidate’s background, their recommendations, interests and who’s in their network
Incorporate a candidate’s full profile data in your careers site
Make it easy for qualified candidates to apply to your company’s jobs
And in a few days I received an answer that my access to API is restored!
Thanks LinkedIn Review Team, they are great guys!