OWA Message compose origin detection from add-in - outlook

I have been wondering, is there a way to detect whether the addin is running in the deeplink version of the message compose or in the normal owa message compose via the "usual route" ?
Deeplink(https://outlook.office365.com/mail/deeplink/compose)
Usual route (https://outlook.office.com/mail/inbox ---> New Message)
What I tried:
1) window.location.href gives me the location of the js page in my webserver.
2) parent.document.location gives me "Uncaught DOMException: Blocked a frame with origin "https://localhost:3000" from accessing a cross-origin frame.".
I read that (for security reasons) an IFRAME can only read the origin of the pages in the IFRAME itself.
Can the office-js library natively detect which message compose link is being used?

There is no way / api to detect this currently.
Thanks to #Outlook Add-ins Team - MSFT

Related

Teams Tab API access to Sharepoint FIle Contents causing 405 on OPTIONS call

In Microsoft Teams, I have crated an App that lists files of a certain type in a Tab
The use case is that the contents of the file need to be read by my Javascript
the Javascript in the Tab already successfully gets an ID Token and Access Token (via ADAL)
this code already successfully lists the DriveItems in the group the current logged in user can see
via https://graph.microsoft.com/v1.0/groups/${groupId}/drive/root/search(q='{pdf}');`
when I attempt to GET the DriveItem via
https://graph.microsoft.com/v1.0/groups/${groupId}/drive/items/${itemId}/content
where the itemId is returned from the first call
I successfully see the HTTP 302 from the https://graph.microsoft.com endpoint redirecting to https://<thesharepointsite>.sharepoint.com/<etc>
Axios (and the Microsoft Graph Javascript API) are successfully traversing to the redirect
Postman, with the same https://graph... URL with the AccessToken successfully downloads the binary content from the 302 redirect (so it is not an Auth issue)
PROBLEM
in Microsoft Teams, inside my Tab, the browser (built inside of the Teams desktop app) HTTP calls to https://<thesharepointside>.sharepoint.com respond with a 405 error on the OPTIONS call
usually this means there is a CORS issue, and so the solution is to add the domain to the validDomains of the app
Attempted Solution
the Manifest has the following entries in validDomains
"validDomains": [
...
"*.sharepoint.com",
"graph.microsoft.com",
"login.microsoftonline.com"
]
manually add the full domain the the Teams App's Manifest
use the suggested "{teamsitedomain}" as per https://learn.microsoft.com/en-us/microsoftteams/platform/resources/schema/manifest-schema#validdomains
*.sharepoint.com as per above
use the Microsoft Graph Javascript APIs
In all instances, I get 405 on the OPTIONS call
No file download from within the Tab within Microsoft Teams.
Suggestions?
THIS MAY answer your question in the future
my code now does a https://graph.microsoft.com/v1.0/groups/${groupId}/drive/items/${itemId}
this is an Instance of DriveItem and returns a property on the JSON response:
#microsoft.graph.downloadUrl
as per Microsoft Graph API Download File content return Unauthorized 401 this is a short-lived URL you can traverse without Auth headers
the content of my file was returned successfully (no CORS issue)
I can now download the contents of the DriveItem within a Tab
I hope this helps someone

HTTP 401 for osfruntime_strings.js while loading add-in

I'm facing HTTP 401 for osfruntime_strings.js while loading my OWA add-in on IE and Edge browser. This is working fine on Firefox and Chrome browser.
If I try to load the url on IE/Edge browser in a separate tab then there's no issue, I get HTTP 200.
As this is the first web request made when I try to load my add-in and it fails, my add-in UI doesn't load There is no web request made to load the add-in html page and other subsequent web requests.
Is this something that needs to be fixed on the add-in side or on the Exchange server side.

privateNetworkClientServer error when using geoserver with cesium

I have a geoserver hosting imagery over http. my client site uses https. I've been using openlayers and it all works perfectly. now i'm trying to move to cesiumjs and i'm not getting any imagery in IE or Edge (i am unable to test other browsers unfortunately). i can get imagery in my client if using bing maps, so the client code is functional otherwise. from the browser console i see:
SEC7117: Network request to http://[myserver]:8080/geoserver/cite/wms?service=WMS&version=1.1.1&request=GetMap&styles=&format=image%2Fjpeg&layers=cite%3Abmpyramid&srs=EPSG%3A3857&bbox=195678.7924100496%2C156543.03392804041%2C234814.55089206248%2C195678.7924100496&width=256&height=256 did not succeed. This Internet Explorer instance does not have the following capabilities: privateNetworkClientServer
and:
SEC7111: HTTPS security is compromised by http://[myserver]:8080/geoserver/cite/wms?service=WMS&version=1.1.1&request=GetMap&styles=&format=image%2Fjpeg&layers=cite%3Abmpyramid&srs=EPSG%3A3857&bbox=195678.7924100496%2C195678.7924100496%2C215246.6716510579%2C215246.6716510579&width=256&height=256
the URLs are good; i can copy/paste into a new browser and get tiles back. from the browser network tab of the dev tools i can see there are no outgoing image requests.
does anybody know of a way to get around this?
Despite the cryptic error messages, it seems this is not an HTTP/HTTPS issue like I thought; it's a Cross Origin Resource Sharing (CORS) problem specific to WebGL/CesiumJS. It is summarized near the bottom of this page: https://cesiumjs.org/tutorials/Imagery-Layers-Tutorial/ .
Basically there are two options. First, you can enable CORS in your geoserver. I confirmed this did indeed resolve the issue in my dev environment. However, this is not really an option for us in prod.
The other option is to set up a proxy where instead of cesium directly requesting tiles, it requests them from your own web server and your web server fetches them manually. when going this route, you modify your cesium like so:
layers.addImageryProvider(new Cesium.ArcGisMapServerImageryProvider({
url : '//server.arcgisonline.com/ArcGIS/rest/services/World_Street_Map/MapServer',
proxy : new Cesium.DefaultProxy('/proxy/')
}));

Google OAuth API not working anymore?! 404 error

I've got a strange problem with my Analytics Windows Phone App. It's been 2 months now from the first release. My Google Oauth always worked... until several days ago.
It is impossible to authorize the app to access Analytics data anymore. And I've changed totally nothing!
The first URI I use is:
https://accounts.google.com/o/oauth2/auth?redirect_uri=http:// localhost
&response_type=code
&client_id=*myClientAppId*
&approval_prompt=force
&scope=https://www.googleapis.com/auth/analytics.readonly
&access_type=offline
It's the same as https://developers.google.com/oauthplayground/. The Web Explorer shows me the login form, and then the authorization form. When I tap "Authorize access", it redirects me to a 404 page.
I don't know why, it always worked before.
EDIT: OK, this works in Google Chrome. It gives me a 404 at the end but the code is in the browser URI.
EDIT 2: It works in Firefox too! But not in Internet Explorer. Google has modified something that doesn't fit IE! As it is IE in Windows Phone, I'm out of luck.
EDIT 3: This is the URL from Windows Phone IE during the process:
https://accounts.google.com/o/oauth2/auth?redirect_uri=http://localhost&response_type=code&client_id=*clientID*&approval_prompt=force&scope=https://www.googleapis.com/auth/analytics.readonly&access_type=offline
https://accounts.google.com/ServiceLogin?service=lso&passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&ltmpl=embedded&shdf=Cp8BCxIRdGhpcmRQYXJ0eUxvZ29VcmwaAAwLEhV0aGlyZFBhcnR5RGlzcGxheU5hbWUaGkFuYWx5dGljcyBmb3IgV2luZG93c1Bob25lDAsSBmRvbWFpbhoaQW5hbHl0aWNzIGZvciBXaW5kb3dzUGhvbmUMCxIVdGhpcmRQYXJ0eURpc3BsYXlUeXBlGhJOQVRJVkVfQVBQTElDQVRJT04MEgNsc28iFJZQrUSzSBUX1XVpZxx-K_xFjAA7KAEyFBX1s-5Zjlet_038EBgHpUrtzMWT&scc=1
https://accounts.google.com/ServiceLoginAuth
http://accounts.google.fr/accounts/SetSID?ssdc=1&sidt=ALWU2cvavauNt1Z0SXgI2DX+i+T5G1snNnu5C+aq/NBExAfG+WenK3WQRLVDLUWqsRcCCbj6c1b1qoZUOQminXYpKJMQzl6FWmuTgA8rVQYtaK5tatpCXffmlXh9CLec/zn8SUijYZILc7vwN9ByicxS1vSyFGvuoteb7wfDiemkcbvaPjfQZ4PrfmEWtl/Us+Gua+ePdTMc9tHFllBYj3TUZDiL7H1FmfPe1nE4jPyteAnGcF500lFyGSYAftGVpsMRQZiJ+4qVhGcgBrFrySpb92sVTq5FGTrQmqryhvhwQF6Sy6SJbq1CqgiavbsZbfwrvZIWVq31&continue=https://accounts.google.com/ServiceLogin?passive=true&go=true&continue=https%253A%252F%252Faccounts.google.com%252Fo%252Foauth2%252Fauth%253Fscope%253Dhttps%253A%252F%252Fwww.googleapis.com%252Fauth%252Fanalytics.readonly%2526response_type%253Dcode%2526access_type%253Doffline%2526redirect_uri%253Dhttp%253A%252F%252Flhttps://accounts.google.com/ServiceLogin?passive=true&go=true&continue=https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&shdf=Cp8BCxIRdGhpcmRQYXJ0eUxvZ29VcmwaAAwLEhV0aGlyZFBhcnR5RGlzcGxheU5hbWUaGkFuYWx5dGljcyBmb3IgV2luZG93c1Bob25lDAsSBmRvbWFpbhoaQW5hbHl0aWNzIGZvciBXaW5kb3dzUGhvbmUMCxIVdGhpcmRQYXJ0eURpc3BsYXlUeXBlGhJOQVRJVkVfQVBQTElDQVRJT04MEgNsc28iFJZQrUSzSBUX1XVpZxx-K_xFjAA7KAEyFBX1s-5Zjlet_038EBgHpUrtzMWT&service=lso&ltmpl=embedded&fss=1
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&pli=1&auth=DQAAAIMAAAAw6WtQDD3JKEg_qAs6neUVzWA5ixsW0ido7pIOrK5KRLnHA-_QQhVd7RzSelpNhkhCVJxVGSEgQpZINeKa29lwivfu-Rbu-vuM1uR4U-JC3EJZEwDMIMuva19_KNsd83ihmeYcuGbnBvUR5iln1KhZZIvhUkbS9CjVwLRdwbMRG5nRHO-oJruBkuezuntX8Iw
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/analytics.readonly&response_type=code&access_type=offline&redirect_uri=http://localhost&approval_prompt=force&client_id=*clientID*&hl=fr-FR&from_login=1&as=-f41460280d51b31&pli=1
https://accounts.google.com/o/oauth2/approval?as=-f41460280d51b31&hl=fr_FR&xsrfsign=APsBz4gAAAAAUHsS0dCApfLAWpZILWjeTNZSt6DUZzug
404 error -> https://accounts.google.com/o/oauth2/
On Chrome, same URIs, but when I click on "Authorize", I get localhost with the code for the token.
I believe in WP, embedded IE webview has javascript disabled by default. There's a simple webview API call to enable JS before starting the webview. At this point, we can only reproduce this bug in browsers that do not execute JS.
More specifically, see: http://msdn.microsoft.com/en-us/library/microsoft.phone.controls.webbrowser.isscriptenabled(v=vs.92).aspx on how to enable JS.
We've identified an issue with our server that we hope to fix soon for the way we report an error when JS is not enabled on the client.
Clients that do not have javascript enabled will not be able to submit the OAuth approval form going forward. The error you're seeing, with the 302 to the 404 is a redirect bug in our error page that explains this requirement.
In addition, we have tested windows phone 7 IE on our page and recreated your issue. At this point we assume is related to JS in the client. We're looking into this and hope to have a fix soon.

Responding to server response

I'm using WebBrowser control functionality to implement web browser capabilities in my project. Is there a way that when my browser (which I have developed by using WebBrowser control) sends a request to a server (lets say to download a file), instead of the browser handling the response, I would be able to handle it myself in my project?
Thanks in advance.

Resources