I'm seeing an issue with my Outlook Add-in (running in Outlook 2016) where when I open a popup window using window.open, it sometimes opens in the user's default browser (e.g. Chrome) instead of the browser running the add-in (e.g. the IE11 web view embedded in Outlook 2016). This is a problem because it prevents the popup window from communicating with the add-in, which is necessary for clickjacking protection.
Is there a way to force the popup window to be opened in the same browser that is running the add-in, without using the Dialog API? I would like to support requirement set 1.3.
You should check to see if the displayDialogAsync API exists. It was added in requirement set 1.4.
If it exists, we recommend using it. Please note that the dialog can only call the Office.context.ui.messageParent API. This API allows the dialog to communicate one-way with the add-in. The add-in can use those messages to leverage the Office.js APIs.
If the displayDialogAsync API doesn’t exist you can leverage window.open. However, in this case the default browser will not be launched.
As 2022 docs were updated.
The API documentation was moved from dev.office.com (these links don't work anymore) to learn.microsoft.com. And here you will find an example on how to use this api.
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've been able to make an Office Taskpane Add-In available within Word by placing the manifest XML file on a network folder. What I would like to do, however, is have the manifest file hosted on my webserver that hosts the Taskpane webapp as well and have Office grab the manifest from there.
I tried adding the URL to where the manifest file is hosted to the Trusted Web Add-In catalogs and I see it listed as a catalog of type "SharePoint" (while it's not a SharePoint site, just a regular old http host). My add-in also isn't showing up in Word.
Is there a way for me to host the manifest XML file on a regular webhost and have the add-in made available in Office?
You can side-load add-ins but it isn't recommended for production use. It makes updating the manifest rather tedious at any scale beyond 1or 2 users.
I recommend taking a look at Publish your Office Add-in. There are sever options beyond the network share method. For internal deployments
I’ve got a moss document centre website with FBA and AD authentication enabled. After creating a picture library I seem to have reduced functionality when accessing the site through the FBA URL.
I’ve compared the web.config files from each IIS website and they are the same (apart from added FBA information that's required).
Here's two pictures to illustrate what I mean.
This picture shows the options available in the picture library when accessing the website through AD authentication:
alt text http://www.abbeylegal.com/Downloads/2006-07-26/Ad%20Authentication.jpg
This picture shows the reduced options available in the picture library when accessing the website through FBA authentication:
alt text http://www.abbeylegal.com/Downloads/2006-07-26/FBA%20Authentication.jpg
Anyone else seen this behaviour? I find it really strange.
This functionality is by design. As per Microsoft:
When you configure a zone to use forms authentication, the Enable Client Integration box is cleared by default. If a zone is configured in this way, the following changes occur in functionality:
Support for remote interfaces is turned off. That includes WebDAV, SOAP, and Microsoft Office FrontPage remote procedure calls (RPC). Some functionality is not available, such as Web folders or the Web services for accessing content in that site.
Some toolbar items no longer appear:
New Document
Open in Outlook
Open In Windows Explorer
Export to Spreadsheet
Open with Database Program
Explorer View option is hidden.
Create an Access View option is hidden.
In picture libraries, the following functionality is removed:
Upload Multiple
Edit Picture
Download
Send To
On the Edit Control Block (ECB) menu, the drop-down menu that appears when you click - items in document libraries, the following items are removed:
Edit in Word
Edit in Excel
Edit in PowerPoint
Discuss
Connect To Outlook
In slide libraries the following functionality is removed:
Publish Slide
Send to PowerPoint
Also, syncing SharePoint data with Microsoft Office Outlook no longer works.
Form Authentication will reduce some functionality such as in document library. We won't see the new document, be able to edit it in the spreadsheet, be able to open it with Windows Explorer etc.
For that, we need to enable the feature called Client Integration in Authentication
Provider. After enabling that, we'll get all menu items.
I have a MOSS 07 site that is configured for anonymous access. There is a document library within this site that also has anonymous access enabled. When an anonymous user clicks on a PDF file in this library, he or she can read or download it with no problem. When a user clicks on an Office document, he or she is prompted with a login box. The user can cancel out of this box without entering a log in, and will be taken to the document.
This happens in IE but not FireFox.
I see some references to this question on the web but no clear solutions:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.sharepoint.windowsservices.development&tid=5452e093-a0d7-45c5-8ed0-96551e854cec&cat=en_US_CC8402B4-DC5E-652D-7DB2-0119AFB7C906&lang=en&cr=US&sloc=&p=1
http://www.sharepointu.com/forums/t/5779.aspx
http://www.eggheadcafe.com/software/aspnet/30817418/anonymous-users-getting-p.aspx
To disable login prompt opening office documents from SharePoint 2010 do the following settings in web.config
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
<!-- here's where the magic happens -->
<verbs allowUnlisted="true">
<add verb="OPTIONS" allowed="false" />
<add verb="PROPFIND" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
If Sharepoint Shared Workspace is enabled in MS Word this may prompt users with a Windows login if users do not have permissions to access or create a Shared Workspace. Do the followoing to turn this off:
Open MS Word
Go to Tools/Options
Click General Tab
Click Service Options
Click Shared Workspace
Uncheck box that says “The document is part of a Workspace or SharePoint Site.”
Click OK
Click OK
Try to hit a MS Word document from the SharePoint site.
If this resolves issue repeat steps with every MS Office program to eliminate the prompt. (Excel, PowerPoint, Visio, ect)
http://office.microsoft.com/en-us/word/HP010414641033.aspx
Unfortuantly the only work around I've found breaks some functionality for logged in users (can't upload multiple files, connect to outlook ect..)
If that is acceptable, or you want to try it and see:
In central admin > application management > application security > authentication providers select your web app and select your provider (likely "default").
Select No for client integration and save the settings.
Open your web config, find the line <add verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK..... and remove the verb OPTIONS.
You should no longer be asked in ie for credentials. To reverse this simply undo both changes.
If you can click cancel and it comes up the problem is...
AuthForwardServerList
http://support.microsoft.com/kb/943280
Office doesn't know the site is trusted/local so it doesn't fwd your credentials and prompts you with an opportunity to provide them. It's a feature....
If you list your site in the proper registry key it will forward your credentials which are not needed but you won't get prompted.
If you have a url rewriting module or urlscan, configure the software to send http 403 to http OPTIONS requests.
In the Sharepoint Server 2010, The solution method is a little bit changing because the new generation Sharepoint can not hold verbs in web.config. Therfore, you must change the method. First of all, you open IIS 7.0 and choose your application site. You can see many items at the middle of the screen. You choose and double click Request Filters. In the request filtres, you can see "Verbs". You can add OPTIONS and PROPFIND verbs to a deny mode. And finally test your site. Sometimes, Sharepoint needs to close Client Integration Mode of your site. If need, you can close Client Integration Mode in Central Administration.
Possible cause and resolution:
http://support.microsoft.com/kb/943280
"You are prompted to enter your credentials when you access an FQDN site from a computer that is running Windows Vista or Windows 7 and has no proxy configured"
"For example, when you open a Microsoft Office file from a Microsoft Office SharePoint site by using 2007 Microsoft Office on a Windows Vista-based client computer that has no proxy configured, you are prompted for authentication."
My guess is that the Office client is loading the underlying document template from another location where anonymous access is enabled. This also explains why you can still open the document as the Office client can also work without loading the template the document was originally created from. To see the template URL in Word 2007, enable the Developer Ribbon from Word options and click the Document Template button on the ribbon.
That doesn't seem to be it. Once of the documents in question is an Excel file, which would not use the .doc template. Also, in the Document Template dialog, it doesn't give me a url to the SharePoint template file if I create a new Word document based on it. It just says the template is "Normal." I also tried disabling the template at the document library level and it doesn't change the password situation.
When opening an Office document in IE, an ActiveX component is used to call the client application, and prompt it to open the document. In other browsers, the download is a standard hyperlink, handled by the browser.
Does this happen in search results and in standard linked columns in document libraries as well?
Using a tool like Fiddler (as referenced/suggested in your first link reference, see http://www.fiddlertool.com/fiddler/ for more info) is the only efficient way of determining the root cause of this type of issue I'm aware of. Whatever is causing this will be happening over HTTP. A debugging proxy like Fiddler will show you exactly which URL/resource is causing the request for authentication.
On a related note, are you running a recent build of the platform? It might be wise to check to make sure this issue hasn't already been addressed by MS e.g. in a hotfix. The best list of updates I'm aware of is here: http://www.harbar.net/articles/postsp1.aspx
Check this : Remove Login box when anonymous users download office document from SharePoint Site
http://www.theblackknightsings.com/RemoveLoginBoxWhenAnonymousUsersDownloadOfficeDocumentFromSharePointSite.aspx
When developing Extranet/Internet site in SharePoint you often want to allow anonymous access and this works fairly well.
But there is one are where the out of the box experience fails regarding anonymous access and that is when you allow the users to download Microsoft Office documents. In that case IE/Office pops up a couple of Login dialogs, if the user cancels out of these the document opens as expected, but you really don't want the user to have to cancel a couple of dialogs to open your documents
The problem is that office tries to be intelligent and issues a Microsoft Office Protocol Discovery request to see how much the user is allowed to do, but SharePoint responds with access denied until the users logs in.
The solution I've found is to implement a HttpModule which rejects the Microsoft Office Protocol Discovery request if the user isn't logged in and this gets rid of the Login boxes
I'm guessing that you use Windows Vista. We had this problem on Vista but not on XP.
From Microsoft: In Windows Vista, Internet Explorer uses the Web Client service when you use Internet Explorer to access a WebDAV resource. The Web Client Service uses Windows HTTP Services (WinHTTP) to perform the network I/O to the remote host. WinHTTP sends user credentials only in response to requests that occur on a local intranet site. However, WinHTTP does not check the security zone settings in Internet Explorer to determine whether a Web site is in a zone that lets credentials be sent automatically.
If no proxy is configured, WinHTTP sends credentials only to local intranet sites.
Note If the URL contains no period in the server’s name, such as in the following example, the server is assumed to be on a local intranet site:
http://sharepoint/davshare
If the URL contains periods, the server is assumed to be on the Internet. The periods indicate that you use an FQDN address. Therefore, no credentials are automatically sent to this server unless a proxy is configured and unless this server is indicated for proxy bypass.
This is a known issue that has not quite been completely fixed yet. There is a MSDN blog about it here: http://blogs.msdn.com/sharepoint/archive/2007/10/19/known-issue-office-2007-on-windows-vista-prompts-for-user-credentials-when-opening-documents-in-a-sharepoint-2007-site.aspx
There is an interesting workaround posted here: http://grounding.co.za/blogs/neil/archive/2008/11/10/workaround-sharepoint-keeps-prompting-for-login-when-creating-office-2007-documents-on-vista.aspx
Ultimately there is a patch that has been included with Vista SP1 but it also requires a registry edit. We just recently got this to work using the following steps on a Windows Vista SP2 client:
Open regedit. Navigate to the following subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Create a new Multi-String value called AuthForwardServerList and give it a value of (for example):
https://.Contoso.com
http://.dns.live.com
*.microsoft.com
https://172.169.4.6
Then restart the WebClient service.
We were able to get this working by changing IE settings.
We have the site URL in Trusted Sites.
Under Custom Settings set User Authentication to: Automatic logon with current user name and password
I found a solution. First of all, you open the web application config file under the inetpub. Then you find the add verbs section. In this section, many verbs were added in the installation time. Delete Options and Profind verbs and save config file. Finally test the problem and see it. The problem is finished.
I've found the following workaround:
http://www.objectsharp.com/cs/blogs/max/archive/2008/04/21/sharepoint-public-facing-website-and-microsoft-office-documents.aspx
To keep it simple:
Disable client integration
Remove the OPTIONS verb from the registration line in the web.config file for the site