There are three methods to send Email by Outlook in WEB.API Core .
I can use directly JSon query for Microsoft Graph API or for
Outlook API directly;
I can use library Microsoft.Graph;
I can send in WEB.API Core from program Outlook in the
computer .
In first two situations I must manually with browser log in.
Third way is does not satisfied me cause at server can not be program Outlook .
Is it possible to get Authorization and Authentication without browser, from my server directly ?
You can use the Client Credentials Grant Flow , in this scenario , your web api will call Microsoft Graph to send emails with their own identity and not on behalf of a user ,then no login process :
Get access without a user using Microsoft Graph
My Solution for send Email like from Outlook is I must interact with Exchange Web Service . So this is that what I looking for . This is the four's way for interaction with Outlook . And the best incarnation for this is packet Microsoft.Exchange.WebServices.NETStandard .
Related
Is there any way of authenticating a user via the Office 365 REST API, without registering an application first?
For example, the documentation of Microsoft Graph has numerous authentication scenarios, including how an application can
Get access on behalf of a user
but there is no such scenario for a user calling the REST API with some credentials (e.g., username and password) and gets authentication tokens as a response, so that they can subsequently use the rich functionality provided.
The Azure Active Directory Authentication Libraries (ADAL) provide user-level authentication functionality, but they do not expose the REST API.
There is no way to call the Microsoft Graph without registering an app first. All calls to the graph are authenticated using a OAuth2 flow (of which there are several) and all require an app to be registered.
For your question, I think we can use background daemons or services to get authorize the user.We can use the following steps:
Get access without a user.
We can refer to this document to learning more information.
2.Authorize the user
When we get the user's profile by using the access token in the step one, then we can authorize him by checking him is exist in our system.
On our desktop add-in for Outlook, once we receive a token for the Microsoft Graph API we make a call to retrieve the user's email message from the following endpoint: https://graph.microsoft.com/v1.0/me/Messages/[message_id]
This call to the Graph API is coming from our server, so it shouldn't matter that the add-in UI is running in the browser or in the Outlook client. However, we're seeing that - sometimes - when running from the Outlook client, that the request from our server for the Message gets a 404 response.
I have captured the url and token of both requests from the web browser add-in and the Outlook client add-in, and tested each manually. Both api URLs were the same, and both tokens that were generated (one from the OWA add-in and the other from the Outlook client add-in) worked successfully when I tried them manually with Postman.
Any ideas why the requests from the Outlook client add-ins fail while the web-based add-in requests are successful?
stmcallister--I'd like to restate my understanding of your flow a bit. In your question, you mention that your calls to the Microsoft Graph are coming from your service. Am I right to assume that your add-in is presenting the OAuth flow for your service's Application Id, collecting a Token on its behalf, and then flowing the Token back to the service via an API call? Do you flow Id, Access, or Refresh Tokens to your service?
If this is the case, then as you say it certainly shouldn't matter where your add-in is hosted at runtime. However, it's possible that your Tokens (specifically their claims) are slightly different based on the original login context (Browser vs. Office).
In either case, a 404 is an unfortunate response if there's a Token issue. If you can provide more details about the problem requests, then we can look into it.
Thanks,
-TimMc
Our SharePoint environment uses Claims Based Authentication - using
FBA for external users and AD for internal users.
I have not been able to connect using default credentials or Windows
authentication to a test SharePoint site using the SharePoint Client
Side Object Model (CSOM). I am able to connect using an FBA user but
require connecting using default credentials (assuming this is the
app pool id tied to the SharePoint application) or at least an AD
account.
The message I get when executing ClientContext.ExecuteQuery is - Cannot Contact Site at the Specified URL. I
have researched this extensively and have tried numerous suggestions including the following:
Using an event handler tied to the clientContext.ExecutingWebRequest
which adds to the WebRequest headers. Solution found here
https://social.technet.microsoft.com/Forums/office/en-US/16cd0e26-8f3b-4ef2-bac4-c2c59849ab96/authentication-in-clientcontext-in-sharepoint-2010?forum=sharepointdevelopmentprevious.
Using System.Net.CredentialCache.DefaultCredentials
Using System.Net.NetworkCredential passing in AD account
Thanks for any ideas or suggestions.
Tom
I should have mentioned that we are using SharePoint 2010 and that I'm trying to retrieve and update user profile properties. As I was beginning to code a solution to do this (using my FBA connected ClientContext), I read that in SharePoint 2010, you can only update user properties using the UserGroup web service. I get an Access Denied when trying to connect via the web service. I believe the ClientContext sits on top of the web services so the scenario/issue is the same. Again, any thoughts or suggestions are greatly appreciated.
Well, after much research, it seems that there is a solution. Adding a header to the request programmatically is the first step. The only issue is that in addition to adding the header, you must add an additional Windows authentication zone to SharePoint. I do not want to add another zone to our production environment.
Since the program I'm putting together accesses SharePoint and non-SharePoint databases, I would like to run it on a non-SharePoint server so I will most likely use an FBA account that is specifically created for this purpose.
In case anyone is interested, here is another link explaining how to add the header to the web request. You will receive an error - Object Moved without adding an additional zone. Here is a link which describes adding a zone.
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.
I've been trying to integrate my application (ruby) with a Google AppScript (published as a Web Application with access level as 'only me') on behalf of a Google Apps account for quite some time, but I can't get a handle of it. Maybe I'm missing a key concept here or that sort of authentication/authorization isn't available when making requests in the background.
The script works fine when I'm logged in to gmail and access the script endpoint. I can also successfully connect to it using a sinatra application authenticated with openid.
I've already tried to use google-api-ruby-client, but I can't get the authorization scope right (service name). I've also tried clientlogin in gdata-ruby-util, to use Gmail login/password and get an authorization error message when trying to fetch from the script url.
Is it doable? Can anyone point me in the right direction?
Unfortunately, Contentservice in Apps Script (which I think you are using to create your webservice) doesn't provide any authentication mechanism. If you are accessing it from a server side script, you can use a token string which is known by your webservice app and your server to provide a level of security to your publicly accessible webservice.
Here are some similar discussion
How to use Google Apps Script ContentService as a REST server
Google App Script: ContentService web app usage