I've got a mysterious edge case with some Word 2016 users on Windows using my Word add-in.
I realize much more info might be required...but I also feel this is an issue that might have some proven ways to diagnose - or someone may know of a root cause.
My simple Word add-in pulls data from a MySQL db on my web server (via php) and stores it in localstorage. Works great in Word 2016 on multiple computers. A handful of users can't, essentially, download data and my solution throws errors for them.
I've even had 2 users on the same machine - one who can use my add-in, one who cannot (so each logging into different Windows accounts at the same institution. The user who was able to happily use my app is in IT and maybe had different settings).
My nose tells me there is an Internet Explorer security setting getting in the way...we've verified that localstorage is allowed.
When a user with the problem opens Internet Explorer directly, they're able to download data and use the app (part of it works outside of Word). As I understand it, Word 2016 Add-ins use Internet Explorer 11 to render html/js/css - and a setting changed in a user's IE11 settings area will cascade to Word 2016 add-ins.
Some of the weird details I've picked up:
Opening a new browser window from inside Word (clicking on a link in my add-in that opens a full web browser) prompts a "A website wants to open web content using this program on your computer" and points to Internet Explorer's Protected Mode. I've experimented with turning this on myself and can't recreate the issue.
The user isn't signed into O365. That doesn't seem to make a difference either.
Debugging via F12Chooser shows an [object error] with an error code of "-2147024891" and a "stack" message of "Error: Access is denied..." at the point where data would be pulled...I can't get much more out of the console.
The add-in is able to hit Firebase (I'm using Google's Firebase for authentication) and I get a response from their server...but not my ajax call to my php file.
Any thought or direction appreciated.
Related
In Sharepoint we have a report created by Visual Studio-ssrs. When the report is executed and the results are shown, when I click on actions/export/excel (or other formats) I receive a message at the bottom of the screen saying that the file ‘couldn’t be downloaded’. The same happens when i try to export a sharepoint list to excel (therefore this is not a problem of ssrs only )What can I do? I have the following additional information for the problem:
- I use IE11 32 bit Excel 2016, SQL/Visual studio 2008.
- I have no problem in downloading any file from Sharepoint (eg from document library) or from internet.
- When I switch user and log in (in the same pc) with another user of the network I do not face the above problem and the file is saved normally
- When I switch user the settings change. I make the settings of my user the same as the settings of the other user (Internet options/security/custom level and internet options/advanced) but there I still have the above problem.
- when I log in with my username to another pc I have no problem.
- I reset IE but I have the same problem.
- I check from manage add-ons and I have the same add-ons as with the add-ons I have when I log in with the other user. The only difference is that in the ‘run without permission category’ the add-on ‘SharePoint OpenDocuments Class’ appears three times compared to two with the no-problem user. All have the same version (15.0.4420.1017)
I found the solution. I run the Internet Explorer as an administrator and the problem was solved.
I've been going through the process of submitting a JS based add-in to the Outlook store through Microsoft's Seller Dashboard and I'm receiving the feedback:
Requirement:
Your app or add-in must not stop responding, end unexpectedly, or contain programming errors.
Error:
We encountered an error while testing your add-in.
When authenticating your add-in, we receive an error message and are unable to load your add-in.
Unfortunately there's no other information related to this request making it hard to debug or understand what is happening.
We've tested successfully on Outlook 2016 (Windows 10), Outlook 2016 (Mac OS), outlook.com (on Safari, Chrome, Firefox, and the latest version of IE) and other than a few peculiarities with how the desktop versions of Outlook handle things everything is working.
The only thing I can think of that may be triggering this is that we have a whitelist CORS approach. Currently we've whitelisted the domain our add-in is served from, but if Microsoft is bundling our add-in we'll need to whitelist the location it's eventually served from.
Is it likely that it's a CORS issue?
If so, what domains should we be whitelisting?
If not, how do we debug this given it works on outlook.com, Outlook 2016, and Outlook for MacOS when side loading from the same manifest xml document we're submitting through the seller dashboard?
Unfortunately the Office Store review team will not give many details that could be helpful. You have to provide as much testing information as possible in order for them to succeed. I had a similar loading issue at one point and they did not even bother to provide the browser type or version.
A good strategy is to output as much debugging information as you can to the browser console from your add-in's key functions. If you ask them to provide these logs in your testing notes they may be able to do that for you.
Note that the location your add-in is being served from is always your web server; Microsoft just hosts the manifest for the Office Store.
The error message that the screenshot is illustrating that the webpage your manifest is directing Outlook to load is not available. This means that when Microsoft is attempting to validate the add-in, the web server that the add-in is pointing to is returning a 404 HTTP Response.
I have written some code to connect to a SharePoint online server and get a list of *.docx (Microsoft Word) files from a folder on there.
I then display this list of files in a web page and each file is a tag, so that the user can click on it and "open" the file.
When the user clicks on the file, it prompts the user to Open/Save the file (the standard IE/Chrome file open/save dialog). Instead, I want the file to open up in Word Online (in the same/separate browser tab).
I tried searching for possible API support online, but can't seem to find any. SharePoint Online itself seems to be able to do this. If you click on a .docx (or any other Office file), it will open it in Office 365 (provided you have that provisioned).
Any help would be greatly appreciated.
You need to add the appropriate parameters to the link that the user clicks on.
Have a look at an existing document library and see the links that it creates:
https://mytenant.sharepoint.com/_layouts/15/WopiFrame.aspx?sourcedoc={1767368F-62FB-4C40-B3F2-C4EE44E88735}&file=My%20Document.doc&action=default
If the user is not licensed for Office 365, I think that they will still be offered a download. Not entirely sure though as we don't allow that on our tenancy. Certainly if they are only provisioned with SP Online and not the rest of O365, they can view the document online but cannot edit. Though recently we've seen people still able to edit - not yet sure if that is one of Microsoft's secret updates or a mistake by them.
RESPONSES TO COMMENTS:
When I say not provisioned in the rest of O365, I really meant that they were licensed for SharePoint but not anything else (a P2 license rather than an E3), that doesn't give rights to use the online (or iPad) editors. As far as I know, the only real way to test for that is to either try it or to use an Admin account to look at the license.
You cannot "pass credentials" to WOPI since credentials for Office 365 applications come from a separate system. You have to get credentials before you are allowed to access anything in Office 365. Basically Azure AD is the service & the login is done via login.microsoft.com, the login provides a token to your browser that is exchanged with the server on every request. To reuse an existing credential, you have to be using an application that "knows" you have already logged in. Typically, Microsoft use a helper application that picks up the login from IE if that's how you logged in and makes it available to other applications such as Office. If you are using Firefox to log in, IE & Office may not know that you have done so (though there is a plugin for FF that gets installed if you let it which does the same thing).
By the way, if you know how it REALLY works, please don't shoot me down for trying to simplify the process for others. :)
I've created a simple (asmx) web service which returns a DataSet.
I've added the webservice to my Excel 2007 workbook using the Data -> From Web button and I'm able to view / refresh the data.
The problem comes when I need to secure the web service: I've turned on Windows authentication for the web service and the request uses SSL.
Unfortunately, the user's logged on windows credentials aren't used by Excel when trying to refresh the data - the refresh fails.
If I click on Data -> Connections -> Properties -> Definition -> Edit Query, only then am I prompted for my windows credentials and does the refresh then succeed.... not a problem for me, but not something I want every user of this spreadsheet to have to do... any ideas how to make the prompt come up when the refresh is attempted instead of having it fail??
Thanks!!
Update Answers so far are to do with SharePoint and Excel Services (neither of which are any use to me)... and one link for which "The following procedure does not apply to data that is retrieved from a text file or a Web query"... I just want a person with a copy of excel on his desktop machine to be able to update from a password-protected web service... is that so hard Microsoft??
Another Update Still no answers accepted - because no answers so far have provided a working solution ( Nice googling though - thanks guys ;-) )
While I haven't got SSL I can attest that Excel normally shouldn't ask you for authentication when using pass through authentication.
My guess is that you will need to add the destination website (with the https) to your trusted zone in IE. The effect should be that when you go to the website you shouldn't be challenged for your password at all. IE will now pass through the authentication credentials because the destination is in the trusted zone.
Once this is fixed Excel should treat it like a normal website.
Here's a link which talks you through adding your site to the trusted zone: http://www.nateirwin.net/2007/01/19/enabling-ntlm-authentication-in-firefox-and-internet-explorer/
The last time I dealt with this issue was in 2004. If I remember correctly, this is a bug in the Web Query technology in how the query deals with the SSL certificate. This is Excel 97 technology; therefore, fairly basic implementation.
After much research and troubleshooting, the only way around this issue is to create user and password parameters and post the web query. Using POST will keep the user/password hidden from prying eyes.
Following is my note from 2004: There is a problem with https, application/vnd.ms-excel, Internet Query (iqy), and Excel 2000/2002.
Have you checked out this question: What do I need to do to make Excel access a Web Query via HTTPS?
Excel's Web Queries Enable You to Populate Worksheets from Web Sites at http://msdn.microsoft.com/en-us/library/aa155714(v=office.10).aspx.
Sites requiring authentication and passwords provide additional
challenges. They may require coded workarounds or may be unsolvable.
Error message when you use Web query to a secure Web page () in Excel: "Unable to open" at http://support.microsoft.com/kb/290347.
XL97: How to Create Web Query (.iqy) Files at http://support.microsoft.com/kb/157482 is an invaluable resource. (There was a Web Query SDK once that I cannot find, but this article is a good replacement.)
Different Ways of Using Web Queries in Microsoft Office Excel 2003 at .
I don't know if this will help, but I faced a similar situation while importing data from a remote SQL Server Database. What I did was create a role inside the database itself, and assign any users who needed access to that role.
The data is updated into the workbook when the file is loaded using Microsoft Query, so I don't know how that might differ from how you have done things.
The biggest issue with doing it this way was to open the properties for the query and check the "Use Trusted Connection" box. This worked without an issue for me. Again, this was from a remote server, not a secure website. Hope this helps.
i hope this will help you : Refresh connected imported data
We had a similar situation at work, however, we are using Office 2010. I'm not sure of the limitations of 2007. Check out these links. The last two are specifically for Excel 2007.
Link 1: Configure Secure Store Service for Excel Services
Link 2: Ten Tips for Using SharePoint Server 2007 with Excel Services
Link 3: Plan external data connections for Excel Services
We have several sites that use Forms Based authentication (FBA) within SharePoint. Many of them have been running for months without issues. Within the last week or two we have noticed the following behavior for users trying to access a Read Only Microsoft office document (currently only verified with the 2007 versions of Excel and Word).
The behavior we are seeing exhibited:
The Document starts to open
Within the Office application an IE Window opens with the FBA login screen. There is also a Hyperlink in the top left saying Skip to main content
Clicking cancel several times will open the document
If you identify the site as an IE Trusted site the login screen with the Office app, everything works as before (not an option for the majority of our sites)
Non offices files, like PDFs, do not exhibit this behavior
Non IE Browsers that we have tested (FireFox, Chrome) do not exhibit this behavior.
Is anyone else seeing this issue? I assume it was an update sent from Microsoft that has resulted in this issue, since we are seeing it on multiple sites where the code has not been updated.
Thanks
The issue we ran into is there was a policy file applied on our network that caused the UAC prompt to be disabled for Vista/Win 7. When this happens, protected mode gets turned off for the IE browsers, which caused the issues we were seeing.
If you want Office integration to work under forms authentication you should do the following:
Turn on client integration in Central Administration for the forms-auth-enabled application
Use persistent cookies for authentication in the forms-auth-enabled application
On the client computer, add the site to trusted sites in IE
If you still see a login screen embedded in Office documents that you open, try the following on the client computer (if Windows 7):
Go to Control Panel, User Accounts
Click Manage User Account Control Settings
Change slider to Never Notify
Click OK and reboot the computer