 |
|||||||||
|
|||||||||
|
|
Recently I encountered a situation in which I needed to access data from a network share and render some of that data in a Web Part. Obviously in this situation I would love to have the data on the share exposed by a Web Service or even a nice POX endpoint. Unfortunately, that doesn't always happen - especially when we don't own the network share that contains the data we're consuming.
So, I figured "no problem" and got to coding. I created a Web Part and wrote some code to create a new instance of XmlDocument and load it up with data found in \\server\share\file. Unfortunately, when I hit the page on which the Web Part resided, I got some nasty error messages about unauthorized access and denied permissions. So, like anyone in my shoes, I completely opened up security, gave my lab MOSS server full trust instead of minimal, made sure that my public key was fully trusted on the box...and when that didn't work I actually fully trusted all managed code on the machine!! Still no dice - no matter what I did or where I put the Assembly (note that Assemblies in the _app_bin subdirectory for a virtual server are given Full Trust by default...that info might come in handy!) I couldn't get it to open the file. The problem is that no matter what happens, and no matter what identity under which MOSS runs, code executed underneath MOSS will never truly have full permission - including opening a file on a UNC-named network share.
So here was my workaround:
I created a new IIS site (this way the new site would not be under the authentication and management umbrella of SharePoint itself) and then created a new virtual directory. This virtual directory pointed at the network share and used fixed credentials to access the share. Now, I could point any browser at http://server/virtualdirectory/file.xml and get read-only access to the data and not be dependent on accessing the share. By default, Web Parts are allowed to open files from HTTP URLs.
This might not be the most elegant approach, but in lieu of creating a service wrapper for share-stored data, I like this option. This way I can keep the SharePoint server at WSS_Minimal or WSS_Medium (where it belongs!) and not worry about someone being able to exploit the lesser security state just because I needed to read a harmless XML file over a network share.
I think UR sexy of the mind _,
I share the same mind _,
Do you want to smell my mind? _,
HHhhhhhmmm..... Cooool !
You could hav accessed it if you put a username ansd password behind the
impersonation tag in the config. this identity CAN be delegated to other
machines (maybe nice to know this?)
Impersonating has its side effect.. suppose I am using the user credentials
of the user who is the owner if the site (system account).. MOSS will
always show the logged in user as 'System Account' no matter who logs in..
placing your file at this location does not require any permission to
access it... C:\Inetpub\wwwroot\wss\VirtualDirectories\<port
no>\bin\wpresources
Yes but my issue was that I needed access to an XML file that was in a
fixed location elsewhere. I didn't have the luxury of copying the file to
the sharepoint server. Obviously if you have the ability to copy the data
file locally, then that's preferable over setting up an IIS alias.
Hope this hasn't died off of your radar entirely. A lot of searching
brought me to this entry which implies I'm up a creek. Do I understand
that Web Parts are of such limitation as to never be able to WRITE to a UNC
network Share? Your work around handily provides read access but I wish to
copy a file from local file system (SP server machine) *TO* a file share,
and this work around doesn't quite do the trick for me. Have you any
advice on where to look or should I just accept that Web Part code will
just NEVER have the requisite access however much I might finagle perms
and impersonations?
