I have an understanding problem with permissions on Graph API access to teams.
For example, if I want to use APP permissions to retrieve all messages in a channel, the current documentation https://learn.microsoft.com/en-us/graph/api/channel-list-messages?view=graph-rest-1.0&tabs=http says that I need "ChannelMessage.Read.Group (with resource-specific consent)" permission.
What does the note below mean "Before calling this API with application permissions, you must request access. For details, see Protected APIs in Microsoft Teams."? I think I had tried the access some time ago and failed because I didn't have access to the Protected APIs. Currently it works though, both with "ChannelMessage.Read.Group (resource-specific consent)" and without (I just set permissions for app). Is the note at this point possibly outdated?
Best regards
Anne
I tried investigating this on my end and I was unable to access the protected API using application permissions.
Interestingly, I found a thread in Microsoft QnA related to what you are experiencing and the issue seems to have been reported.
Related
So I have an app where I have enabled google authentication in my firebase project. 25 people I know were authenticated. When I logged in the backend I saw atleast some 80 entries with some weird sounding email addresses which should not be there. I had to delete all the entries manually, known and unknown ones (didn't needed any after sucessful testing). Now that I want to go live, I am really concerned as to how unknown entires entered my firebase authentication records?
This has recently happened 'again' to another new app/project of mine. This time I disabled that unknown email address and took a screenshot (attached).
I really really need to know and understand how safe is data on firestore. If someone can manage to 'hack' the Authentication part and add thir email to Authenticated list of users they may also be able to penetrate the database somehow in future. Please help me in understanding what is happening?
While researching on this, I could only find this similar question but the answer was just not enough explanation for me.
Unknown user in my firebase user authentication (Flutter/firebase)
firebaser here
Since the configuration data for your project is embedded in the application that you send to your users, any user can take that configuration data and then start calling the API with it. This is not a security risk, as long as you secure access to the data within your project correctly for your requirements.
See Is it safe to expose Firebase apiKey to the public?
What it means to correctly secure access to your data is hard to answer, as it depends completely on your use-case.
For example: the content-owner only access security rules allow a user to enter data in the database, and then they can access the data they entered. With these rules there's no risk if anyone uses the API (and not your app) to do the same. The security rules will ensure they only can access data they're authorized for, no matter what the source is the API calls is.
It may be related to the pre-launch report.
https://support.google.com/googleplay/android-developer/answer/9842757?visit_id=637478112313064713-650300184&rd=1#signin
Step 1: Provide test account credentials if your app has a sign-in screen
If your app has a sign-in screen and you want the crawler to test the sign-in process or the content behind it, you need to provide account credentials. Note: You do not need to provide credentials if your app supports 'Sign in with Google', which enables the crawler to log in automatically.
So I guess it is safe.
The user willwhiteapple#gmail.com is the apple testing when your application is in the process of validation from apple before deploy to TestFlight .
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
Why do i get this error message when i try to launch conversation service tool:
Unable to retrieve the list of workspaces. Error: Insufficient privileges
You need delete cookies of your browser. I faced with the same problem but after to delete cookies I could see my workspaces.
I'm one of the developers of the Watson Conversation service and you seem to have uncovered a small bug in the way that the tooling currently operates. We've been able to successfully reproduce this.
In short, when you open up the tooling to train an instance of the Watson Conversation service a call is made to Bluemix for all instances of the Watson Conversation service that you can see. However, due to the way that Bluemix space permissions work, you may be able to see instances that you don't have permission to edit. You should be able to find your service in the dropdown in the upper right corner of the screen.
In order to have permission to edit and make changes to an instance of the Watson Conversation service, you'll need to have dev permissions in the space that contains the instance of the Watson Conversation service. If you'd like to work on that service instance, you'll need to ask the person who owns the service instance to grant you dev permissions in the space. You can find out more about how to do this in the managing team members and roles section of the IBM Bluemix documentation.
I met the same issue
"Unable to retrieve the list of workspaces. Error: Insufficient privileges".
I double checked my permissions and validated that I have the admin access to all services in my space.
Then, I switched to a different browser and was able to navigate to the watson tool login page.So for my case, it looks more like a cookie issue. Thanks #Richard L. 's comment.
I have built a asp.net app that successfully accesses o365 exchange with an App Only Token and Graph. I am now trying to access a specific user's OneDrive for Business files with the same token and a Get request similar to the following:
https://mycomp-my.sharepoint.com/_api/v2.0/drives/simon#mycomp.com/items
but I get the following error:
3001000;reason='There has been an error authenticating the request.';category='invalid_client'
Any idea what is the cause of the error?
It's possible to do app-delegated access to OneDrive for Business today using the direct API endpoint and the Sites.ReadWrite.All app-delegated permission scope in AAD. I'd consider it more "in preview" than supported, so Yina's answer is technically correct. I'm still getting the documentation for how build an app finalized, but we'll be publishing something soon.
Andrew Connell has a good blog post about how to get this setup, available here: http://www.andrewconnell.com/blog/user-app-app-only-permissions-client-credentials-grant-flow-in-azure-ad-office-365-apis
Use of the OneDrive API is possible using this same method.
App Only access to a user's OneDrive is not supported via Microsoft Graph at this point in time.
Background: This is my first standalone web development project, and my only experience in Meteor is building the Discover Meteor app over the last summer. I come from about a year of CS experience as a side interest in school, and I am most comfortable with C and C++. I have experience in python and java.
Project so far: I'm creating a calendar management system (for fun). Using accounts-google, I have created user accounts that are authenticated through google. I have requested the necessary permissions that I need for my app, including 'identity' and 'calendar read/write access'. I've spent the last week or so trying to get over this next hurdle, which is actually getting data from google.
Goal: I'd like to be able to make an API call to Calendar.list using a GET request. I've already called meteor add http to add the GET request functionality, my issue comes with the actual implementation.
Problem: I have registered my app on the developer console and set up Accounts using the client ID and secret, but I have not been able to find/generate my 'API key' for use in the request. Here is the google guide for creating the access token by using my (already) downloaded private key. I'm having a hard time wrapping my head around an implementation on the server side using JS because I don't have a lot of experience with what is mentioned in the HTTP/REST portion of the implementation examples. I would appreciate some help on how to implement a handshake and receive an access token for use in my app. If there is a call I can make or some package that will handle the token generation for me, that would be even better than implementation help. I believe an answer to this would also benefit this other question
The SO answer that I've been referring to so far: https://stackoverflow.com/a/14543159/4259653 Some of it is in spanish but it's pretty understandable code. He has an API key for his request, which I asked this question to help me with. The accounts-google documentation isn't really enough to explain this all to me.
Also an unrelated small question: What is the easiest way to deal with 'time' parameters in requests. I'm assuming JS has some sort of built-in functionality that I'm just not aware of yet.
Thanks for your research. I have also asked a very similar question, and right now I am looking into the package you recommend. I have considered this meteor-google-api package, but it looks abandoned.
Regarding your question about time manipulation, I recommend MomentJS. There are many packages out there; I am using meteor add mrt:moment
EDIT: MomentJS now has an official package for Meteor, so use meteor add momentjs:moment instead of the mrt command above
Below is a snippet of what moment can do. More documentation here.
var startTimeUTC = moment.utc(event.startTime, "YYYY-MM-DD HH:mm:ss").format();
//Changes above formatting to "2014-09-08T08:02:17-05:00" (ISO 8601)
//which is acceptable time format for Google API
So I started trying to implement all of this myself on the server side, but was wary of a lot of the hard-coding I was doing and assumptions I was making to fill gaps. My security prof. used to say "never implement encryption yourself", so I decided to take another gander for a helpful package. Revising search criteria to "JWT", I found jagi's meteor-google-oauth-jwt on Atmosphere. The readme is comprehensive and provides everything I need. Following the process used in The Google OAuth Guide, an authorization request can be made and a key generated for making an API call.
Link to Atmosphere: https://atmospherejs.com/jagi/google-oauth-jwt
Link to Repo: https://github.com/jagi/meteor-google-oauth-jwt/
I will update this answer with any additional roadblocks I hit in the Google API process and how I solved them:
Recently, I've been running into problems with the API request result. I get an empty calendarlist back from the API call. I suspect this is becuase I make an API call to my developer account rather than to the subject user. I will investigate the problem and either create a new question or update this solution with the fix I find.
Fix: Wasn't including the 'sub' qualifier to the JWT token. Fixed by modifying JWT package token generation code to include delegationEmail: user.services.google.email after scope. I don't know why he used such a long designation for the option instead of sub: as it is in the google API, but I appreciate his package nontheless.
I'm quickly becoming proficient in this, so if people have meteor-related google auth questions, let me know.
DO NOT USE SERVICE ACCOUNTS AS POSTED ABOVE!
The correct approach is to use standard web access + requesting offline access. The documentation on the api page specifically states this:
Typically, an application uses a service account when the application uses Google APIs to work with its own data rather than a user's data.
The only exception to this is when you are using google apps domain accounts and want to delegate access to your service account for the entire domain:
Authorizing a service account to access data on behalf of users in a domain is sometimes referred to as "delegating domain-wide authority"
This makes logical sense as a user must be allowed to "authorise" your application.
Back to the posters original question the flow is simple:
1) Meteor accounts google package already does most of the work for you to get tokens. You can include the scope for offline access required.
2) if you are building your own flow, you will go through the stock standard process and calls as explained on auth
This will require you to:
1) HTTP call to make the original request or you can piggyback off some of the internal meteor calls : Package.oauth.OAuth.showPopup() -- go look at the source there are more nifty functions around there.
2) Then you need to create an Iron router server side route to accept the oauth response which will contain a code parameter that you will use to exchange for tokens.
3) Next use this code to make a final call to exchange the "code" for the token + refresh_token
4) Store these where ever you want - my requirement was to store them not at the user level but multiple per user
5) Use a package like GoogleAPI this wraps up Google API calls and refreshes when required - it only works when tokens are stored in user accounts so you will need to rip it apart a bit if your tokens are stored somewhere else (like in my case)