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
Related
I am trying to find the WebDAV address to my onedrive folder for a 3rd party application. Where should I look?
My url is something like this.
https://COMPANYNAME-my.sharepoint.com/personal/NAME_COMPANYNAME_com/_layouts/15/onedrive.aspx .
As per the Moderator of Microsoft,
"Getting the WebDAV URL for your file needs your IT admin privilege. You are using a sharepoint account through your company, so we suggest that you contact your IT admin to access the WebDAV site."
I am the administrator, I am not able to find the page where I can access the WebDav Site.
Thank in Advance.
Regards
Pratyush SINHA
1) Powershell script
The most simple approach is to use OneDriveMapper.ps1 script, posted on TechNet.
Pay attention to the MANDATORY MANUAL CONFIGURATION section inside. If you're lucky, the only thing you would have to change is $O365CustomerName:
####MANDATORY MANUAL CONFIGURATION
<....>
$O365CustomerName = "ogd" # (example, ogd as in https://ogd-my.sharepoint.com or https://ogd.sharepoint.com)
<....>
It would automatically authenticate you and show the appropriate webdav url in log:
<...>
INFO | Retrieving Sharepoint cookie step 2 at https://ogd-my.sharepoint.com/_forms/default.aspx
INFO | username detected, your onedrive should be at \\ogd-my.sharepoint.com#SSL\DavWWWRoot\personal\username_ogd_com\Documents
<...>
You might have to run this script on each logon or so, so that it would authenticate you.
The admin privilege is not required to run the script.
2) Manually, via "Open with explorer"
User can manually access his personal folder with a few clicks.
Using Internet Explorer (it won't work in other browsers) go to OneDrive web page
Switch to classic view (use "Return to Classic One Drive" in the lower-left part of the page; it might be hidden in the Hamburger menu, if you screen is too narrow)
Enable Ribbon (Settings -> Ribbon)
On "LIBRARY" Ribbon tab, click "Open with explorer"
A version with screenshots.
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 created one InfoPath form which is having C# code and i gave security option is 'full trusted' to access infopath object model,and it should be open with Browser.finally i published the Infopath form to SharePoint(by using admin-approved) site.
But when i'am trying to open, it is not opening and giving an error that is 'InfoPath can not create a new or blank form InfoPath can not open the form,To fix this problem,Contact your System administrator'
and in error show details its giving following message.
'The form template is trying to access files and settings on your computer. InfoPath cannot grant access to these files and settings because the form template is not fully trusted. For a form to run with full trust, it must be installed or digitally signed with a certificate'.
please give me a solution.
Unfortunately, if you are using any file system calls in your C# code then you will have to keep the fully trusted setting. As the error message says, any fully trusted form has to be either installed or have a certificate associated with it to run. Infopath is really just a glorified webpage when it runs on a users machine - you wouldn't want a webpage to run unsecurely and have full rights to the machine without the user knowing it.
You should only need full trust if the form accesses LOCAL resources (indivdiual hard drives). If you don't include C# libraries for file/directory access then domain trust should be sufficient and the form will work fine. (Database access, webservices, etc are not local and will work under domain level).
In the Form Setting change the browser enabled documents as "Display as Web Page".
it resolved the issue :)
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
I’m trying to publish an InfoPath form to a SharePoint document library, and have the form be viewable in a web browser.
The problem is that in the InfoPath publishing wizard tells me that although the form is browser compatible, that it cannot be browser enabled because of one of the following:
The Server is not running InfoPath forms services
The necessary features are not available on the site collection
The policy setting on the server does not allow a user to browser enable forms.
Well, I’ve verified that the SiteCollection has an active feature called “Office SharePoint Server Enterprise Site Collection features”, which includes Form Services, so I assume that the first two issues are not the cause
Also, I’ve verified in Central Admin that the Forms Services are configured to allow browser-compatible forms to be viewable in the web browser. So the 3rd reason doesn’t seem to make sense either.
I've tried applying different Security levels to the form: Restricted/Domain/Full Trust, but that doesn't seem to have an effect. I have been able to publish this form to a different SharePoint site, so I'm assuming that the issue is with the configuration of the SharePoint site, not the InfoPath form
Does anyone have any other ideas as to why this might not be working?
Thanks for any help you can provide!!
Make sure in the Form Lib Advanced Setting section you have the Option "Display as a Web page" is set "Opening browser-enabled documents"
Try testing the XSN file against the MOSS server by copying the file to the server itself (c:\temp for example) and running the following command:
c:\temp> stsadm -o verifyformtemplate -filename myform.xsn
The tool STSADM.EXE sits in %programfiles%\common files\microsoft shared\web server extensions\12\bin so add this to your %PATH%.
Post the answer back here if it still baffles you.
Besides the recommendation from #x0n to check if directory has been allocated as usable, check the event viewer and see if anything is showing.
As a stupid but check item go to:
Central Administration > Operations > Convert License Type
and ensure that you have the enterprise Client access listed.