I need to use several EWS requests (e.g. GetUserConfiguration, UpdateUserConfiguration) that are not supported using Office.context.mailbox.makeEwsRequestAsync.
I cannot use the EWS Managed API in my own web service as a broker, and must use XML SOAP requests directly from the add-in's JavaScript (those methods are not available in the Graph or Mail APIs).
There are many examples (like this) showing how getUserIdentityTokenAsync can be used to pass that token to your web service (again, which I can't use) to use there in whatever way you need it.
However, I'm guessing the token retrieved from getUserIdentityTokenAsync is different and cannot be used. As a simple and hopefully appropriate test, I obtained an OAUTH token for my O365 account and used that as the token using SOAPe for a test GetUserConfiguration call and it worked. I then tried using the token from getUserIdentityTokenAsync and it didn't work (401 Unauthorized).
I concede that this may be a poor test, and I admit that at this point it is unclear to me how a SOAP EWS request from JavaScript in an Outlook dd-in can be authenticated without requiring an explicit user login (hopefully it can). And if it can, how do I get the token I need and how do I use it for this kind of client-side request?
You may want to use ews-javascript-api helper in this case. here is the example on how to use this with Outlook Add-ins.
https://github.com/gautamsi/ews-js-api-browser#working-with-plain-jsts-no-module-loadersbundlers
you may use any allowed api (available in makeEwsRequestAsync) with this library. with similar api what is available in Ews managed Api.
Related
I'm attempting to use Google Sign-In with a firebase function following Google's documentation for Google Sign-In for server-side apps, however I'm running into a redirect_uri_mismatch error (unlike the examples in that documentation, I am using Google's nodejs SDK).
The general flow I'm following is to use google's javascript SDK to request an offlineAccessCode() from a user, send that access code to the server (firebase function), use the access code to get an access token and refresh token, and save the refresh token for later use (this is the flow outlined in the documentation).
It might seem like the meaning of the term redirect_uri_mismatch is self-explanatory, but, as stated in the linked documentation, The Authorized redirect URI field does not require a value. Redirect URIs are not used with JavaScript APIs. That line comes from the section "Step 1: Create a client ID and client secret" and is explaining how to configure the OAuth client credentials. This is the only time in the documentation that a redirect uri is mentioned, and there is no indication that a redirect URI is needed when the server uses the authorization code to fetch an access token.
Indeed, the concept of a redirect uri doesn't seem to make sense in the context of a cloud function using an access code obtained from a client. If the server needs to supply a matching redirect_uri as the javascript client (which doesn't seem to be specified anywhere), I'm not sure what redirect_uri the javascript client uses.
So with that background, does anyone have any idea how to solve this redirect_uri_mismatch error?
Or, more generally, any pointers on implementing this auth flow (my cloud function is written in javascript using the google nodejs sdk). I'm finding it very hard to debug this issue.
Update
I realized that the reason why the error message says redirect_uri_mismatch is because I had been testing various values as redirect_uri. When I remove the (optional) redirect_uri param from the request, the response from google's servers is invalid_request: Missing parameter redirect_uri. So google's making it clear that it wants a redirect URI, even as the documentation seems to imply that it isn't necessary for this auth flow. As a larger problem, the documentation doesn't seem to describe how to set up a redirect URI for an auth flow on a single page app.
Ah HA! The answer (as given in this other S.O. answer) is to set the redirect_uri to "postmessage" on the server (firebase function in my case). I have no idea where this answer came from (i.e. I haven't been able to find it in the docs), but it works.
Is it possible to use any tokens from an Outlook add-in for use with authenticating EWS Managed API operations that create or update items?
Apparently the token returned from mailbox.getCallbackTokenAsync can only be used in read operations. I can indeed verify that is a problem because attempts to send emails or call UserConfiguration.Update result in an error:
The requested web method is unavailable to this caller or application.
I have been testing these methods from an ASP.NET Web API App Service in Azure, called from JavaScript in the Outlook add-in.
Apparently mailbox.getUserIdentityTokenAsync can be used to validate a user, but it is not clear if that can be used in conjunction with OAuthCredentials for ExchangeService.Credentials.
Are there any options here? I cannot ask the user for their username and password to authenticate with Exchange. I am certainly willing to use Graph or the Mail API, but AFAIK there are no ways to update user configuration items with those APIs.
You're looking for makeEwsRequestAsync(). Both CreateItem and UpdateItem operations are supported makeEwsRequestAsync.
You can find the full list of supported EWS operations in the documentation under EWS operations that add-ins support.
There is also support for calling into Microsoft Graph via the add-in but as you noted, Microsoft Graph supports a very limited number mailbox configuration options.
I try to call vimeo API from browser's javascript. When I try to get access token (POST https://api.vimeo.com/oauth/access_token) I get 405 response and CORS error.
Is it possible to make API calls from browser?
Generating access tokens are not currently supported in the browser. Eventually they will be in a very specific circumstance.
For now you need to generate your access token serverside and share it with the client. Be careful though, these tokens do not have an expiration so your clients can take them and use them forever.
We will be fleshing out support for browser-based API calls in the future, but it's still a while out.
According to the Google Drive documentation, an application needs a so-called "client secret" in order to interact with the Google Drive SDK -- even if, as in the case of a client-side JavaScript app, the code is plain for all to see. (Of course, it's not really that much safer in any other client-side code, it just makes for a bit more work to find the "secret"...)
So, um:
How is it okay to distribute these "secrets" inside applications?
Is there any reason why that logic wouldn't apply to open source computer programs?
BONUS: Wouldn't it make more sense to just use user-based authentication for such apps, without pretending to authenticate the app as being a specific app?
Whilst it's true that a Client Secret is generated for all apps that consume Google services, the Client Secret is never used by a browser/javascript app. Typically a browser-app (I use the phrase "browser-app" instead of "Javascript app" because a server node.js app is also using Javascript) would authenticate and authorize using the gapi library described here https://developers.google.com/api-client-library/javascript/reference/referencedocs#gapiauthauthorize. As you can see, Client Secret is never used.
So, picking out your questions ...
It isn't OK, don't do it, no need, see above.
See 1
You're conflating authenticating the user with authenticating the app. Both are needed, each for different purposes. In the case of a browser app, the authentication is done using a combination of the client ID, verified against the http origin (which the developer has previously declared to Google). Once the app is authenticated, we can then move on to authenticate the user by leveraging the OAuth authorization mechanism in conjunction with an extant Google session.
I'm currently working in HTTP JSON API for a touristic webapp. The webapp will be developed by a third-party company and it'll consume the API within the browser.
So I need for the API some sort of authentication to the third-party webapp can consume it. I've been researching a little bit about OAuth, but with this, I have a solution for a user-wide but not for application-wide authorization.
Because the webapp will consume the API within the browser(with Ajax), I'm concerned they will have to put the credentials to consume the API in the user browser.
Another solution would be place the credentials for the API in the server-side, but this don't depend on me.
You could always use something similar to google's method, with a client ID and then a private key used to generate a signature.
https://developers.google.com/maps/documentation/business/webservices#generating_valid_signatures
That page has some code samples as well.