I'm writing an Outlook OnSend addin (new style web addin, not old style COM), and would like to use a Service Worker to provide functionality when the user is offline. I've written an addin, and when I hit the addin's html page in Edge, I can see the service worker being installed and caching the addin files successfully.
However, when I run the addin in Outlook Desktop, it appears that the service worker is not being installed. I'm testing this by running Fiddler, and I can see that the adding files are being requested on each run, rather than coming from the cache that the service worker should be creating.
My addin HTML references a main.js (see below), which attempts to register the service worker. To provide some tracing/troubleshooting ability, I make an ajax call to a service. What this tells me is that:
The check for service worker support returns true
The call to navigator.serviceWorker.register never returns (successfully or otherwise)
Using Fiddler, I never see a request for the referenced "sw.js" file. I do see an edge process (microsoftedgesh) attempt to open an https connection to my server, but this doesn't request any files. All other traffic in fiddler is from the web view host component
Are service workers supported for outlook addins? I'm running Outlook version 2004 (12730.20270 click to run) and Windows 1909, so I'd expect Outlook to be using Edge rather than IE 11, and therefore to have service worker support.
For reference, my main.js looks like this:
if ('serviceWorker' in navigator) {
sendMessage('1');
try {
navigator.serviceWorker.register('sw.js').then(function(registration) {
sendMessage('2'); // Never sent
}).catch(function(error) {
sendMessage('3'); // Never sent
});
}
catch(err) {
sendMessage(err.message);
}
}
else {
sendMessage('4');
}
function sendMessage(message) {
$.ajax({
url: "../api/schedule",
type: "POST",
crossDomain: true,
//contentType: "jsonp",
contentType: 'application/json; charset=utf-8',
data: message
});
}
Service Workers are currently unsupported in addins and any Service Workers usage will be disabled in the near future.
We track add-in feature requests on our user-voice page. Please add your request there. Feature requests on user-voice are considered, when we go through our planning process
Related
I was developing a few Office Outlook Web Add-ins and in none of them could I receive an response error message. Independently of the error that API returns I receive the following data object in fail function:
readyState: 0
responseText: ""
status: 0
statusText: "error"
withCredentials: true
Moreover in the Visual Studio or Browser JavaScript Console console I get:
Origin https://localhost:44347 not found in Access-Control-Allow-Origin header.
XMLHttpRequest: Network Error 0x80700013, Could not complete the operation due to error 80700013.
I would like to point out that CORS is enabled on the server, and I got this error independently from the action taken. It is the same when I give wrong parameter or make a typo in url.
I would also like to point out that API is OK, and such a thing does not happen when I request using JS in the browser (out of Office) or applications. I get a normal error messages from the server then.
In the example above the test is from localhost, but exactly the same situation is when hosted on remote web server.
What is wired about this is that I normally get success replies (with code and message).
What I would like to achieve is to get an error response as the server returns them. It is really hard to notify user what may be wrong with his request without this info.
[Edit]
For example, when I do the following request in a Outlook Add-in and I set the fake token I receive the mentioned error (or rather no error):
$.ajax({
type: 'GET',
url: API_URL + "/api/rooms/",
beforeSend: function (xhr) {
$.ajaxSettings.beforeSend(xhr);
xhr.setRequestHeader("Authorization", "Bearer " + token);
},
contentType: "application/json",
});
However, when I do the save request using Advanced REST Client I got 403:
"description": "You do not have permission to perform this action.",
"message": "",
"code": "permission-denied",
"status": "fail"
It happens in all Outlook version for me.
The issue is that the office add-in is sending a request to your web application over HTTP and the web project that gets created (I'm assuming you're using the Office add-in templates from visual studio) is by default configured for SSL, i.e an HTTPS connection. Whilst this is recommended for production apps, for debugging purposes you can simply click on your web project, then in visual studio click view on the Menu Bar - > then select the properties window -> then set SSL enabled to false. (see attached Image)
https://i.stack.imgur.com/Lvybn.png
Hope this helps!
I am new to Office.js API. I am trying to develop Web Add-In for Excel and I need to get data from WebAPI for this I am trying to use ajax but its not working
Here is very simple Ajax code
$.ajax({
url: "http://localhost:61721/api/values",
type: "GET",
dataType:"JSONP",
success: function (data) {
$("#div1").html(JSON.stringify(data));
},
error:function(error){}
});
Update
Is there any alternative way other than Ajax in Office.js through which we can get data from Web API?
From the client, AJAX requests must be send to SSL URIs and those URIs must be declared in AppDomain list of the app manifest. Please refer to: Send POST AJAX request from Office Add-In.
In the same time, if your app has server side portion of code, you may send direct request to any Web API from there. Nobody limit you in technology (REST, microservices, etc.) and nobody check your connection is secure, when using 3rd party resources from your server.
I'm trying to send POST Ajax request for third party service from my Outlook Add-in, but no matter what I tried I receiving Error: Access is denied, and status 0 (request never hit the server).
Assuming we are running IE9 or 8 behind the outlook I tried old school hacks like https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest.
$.ajax({
url: endpoint,
data: JSON.stringify({'1':'2'}),
// headers: {'X-Requested-With': 'XMLHttpRequest'},
contentType: 'text/plain',
type: 'POST',
dataType: 'json',
error: function(xhr, status, error) {
// error
}
}).done(function(data) {
// done
});
Is there is something more I need to implement? Of cause I add my domain to manifest AppDomain property.
Cheers
The following needs to be done to send request to 3rd party service ...
Add the service URI to AppDomain list (you've done it.)
The service MUST have SSL endpoint; "https://your.domain" must be included within of "AppDomain" entry (see above)
The service has to allow CORS requests for your application (hosted Outlook App URI) domain or any domain. This is up to the service creators to allow or disallow client apps connections via Ajax.
As of observation of your code I notices you are sending JSON object, but setting content type to "text/plain". Contact the service creators to get information on what type of the data they accept as request. Usually services allow "application/json", but not plain text.
I'm trying to invoke web service from Liferay portal using proxy. I already managed to do so on IBM WebSphere portal, like this (invoking 'help'):
<portal_context_path>/proxy/http/<server_url>/<application_name>/help?lang=myLang&object=myObject
I'm making a call using ajax:
try {
$.ajax({
url: 'http://localhost:8080/LiferayTest-portlet/proxy/http/localhost:9081/ServiceApp/help?lang=myLang&object=myObject',
headers: {
'Accept': 'application/xml; charset=utf-8',
'Content-Type': 'application/xml; charset=utf-8'
},
success: function(xml) {
...
},
error: function(xhr, textStatus, errorThrown) {
...
}
});
} catch (e) {
...
}
The thing is, if I make that ajax call on Liferay portal, I get error (404 Not found), but if I call it from WebSphere portal (URL:http://localhost:10039/.WebSphereTest/proxy/http/localhost:9081/ServiceApp/help?lang=myLang&object=myObject), it works.
Is there a similar way (like using /proxy/http) to accomplish this on Liferay portal?
Is your application running inside of Liferay, and you're trying to call something outside, through a proxy? In that case accessing Web Services is just like anywhere else. Use the library of your choice to do this. Liferay does not provide a proxy for you - I don't see what that would bring to the table if it did.
Edit: If you want to access your portlet's "resource" phase, e.g. the request phase that is typically used for Ajax, you'll just have to obtain a resource-URL from Liferay. URL generation is the business of the underlying platform and well standardized. You seem to be using a Websphere-specific way. In a JSP you'd just use <portlet:resourceURL/> to obtain the URL that's handled in your portlet's resource-phase e.g. serveResource(...).
Yet another option is to deploy servlet-based web services with your portlet (as it's technically only a web application) but this is totally outside of the portlet realm and would have nothing to do with Liferay at all.
Ruled out in the comments, I'll still leave this paragraph in here: In case you want to consume Liferay's own API Web Services, they're available as JSON and SOAP. The SOAP services are available on localhost only, unless you configure them to be available to more hosts. Just like before, I don't see the point of an explicit, platform provided, proxy.
Recently I got to the point to host a static webpage with a subscription option on aws s3 while website development is undergoing. My static web page makes an ajax call to another RESTful service with an email of a subscriber as a parameter. When subscription is done I need to notify a subscriber. Here it seams an issue with the callback.
$.ajax({
type: 'GET',
url: 'http://www.my-domain.com/api/Subscribe?email=' + email
}).success(function (data) {
if (data) {
alert('Thank you for registering!');
}
});
After subscription is done ".success(" doesn't fire up. Response on the request is:
Reload the page to get source for: http://www.my-domain.com/api/Subscribe?email=john.smith#simplyemail.com
Does anyone know if it's an s3 feature or something else?
As per your description this seems to be related with CORS policy.
Look to "why CORS" as Amazon defines it:
In order to keep your content safe, your web browser implements something called the same origin policy.
The default policy ensures that scripts and other active content
loaded from one site or domain cannot interfere or interact with
content from another location without an explicit indication that this
is the desired behavior.
In certain cases, the developer of the original page might have
legitimate reasons to write code that interacts with content or
services at other locations. CORS provides the mechanism to allow the
developer to tell the browser to allow this interaction.
I understood that:
[...] ajax call to another RESTful service[...]
Means call to another server, and this may be blocked by Browser because of CORS.
References:
Mozilla
W3C