|
|
You're in the
iis security
group:401 Unauthorized trying to read SPList Attachment - owssrv.dll
iis security:
Please do not post WSS programming questions in future to the main WSS
newsgroup but only to the newsgroup specially created for WSS programming questions. We are maintaining a clear split where WSS Programming questions go only to microsoft.public.sharepoint.windowsservices.development and not to the (Administration issues) main newsgroup microsoft.public.sharepoint.windowsservices. This split is to the benefit of the readers of one or both these newsgroups. Thanks. Mike Walsh, Helsinki, Finland WSS FAQ at http://wss.collutions.com Please reply to the newsgroup [quoted text, click to view] "Chris Kane" <ChrisKane@discussions.microsoft.com> wrote in message news:3DA9A3DB-FD45-436E-99B5-265B002F81B3@microsoft.com... > We have written a class that enumerates the items in a WSS list and then > attemptes to open the attachment for each item. We have written two > classes, > one to impersonate a user and read in the list information and the other > to > be called by the first which actually opens the attachment. Our code > fails > when it tries to open the attachment in the second class with a 401 - > Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. > What's > strange is that I can use IE to open the URL to the attachemnt without any > problems. I noticed in the IIS logs that when I open the URL, I can see > the > domain\password passed to IIS from IE. However, when our code tries to > access the same URL, no user information is passed, causing the 401. We > have > impersonated a valid user in our code, so why does IIS not see it? > > Thanks!
We have written a class that enumerates the items in a WSS list and then
attemptes to open the attachment for each item. We have written two classes, one to impersonate a user and read in the list information and the other to be called by the first which actually opens the attachment. Our code fails when it tries to open the attachment in the second class with a 401 - Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. What's strange is that I can use IE to open the URL to the attachemnt without any problems. I noticed in the IIS logs that when I open the URL, I can see the domain\password passed to IIS from IE. However, when our code tries to access the same URL, no user information is passed, causing the 401. We have impersonated a valid user in our code, so why does IIS not see it?
IIS does not see your impersonated user because you failed to authenticate
as that user. Remember that we are talking about HTTP, which has its own publicly defined authentication protocols. Client-side impersonation isn't one of them. The identity of the user on the client, impersonated or not, means ABSOLUTELY NOTHING on the server unless you negotiate HTTP authentication of some sort. IE, for example, does this authentication behind the scenes without you noticing. So do many of the Windows programs and protocols. This isn't how the web and HTTP works, though, and you just have to follow the rules. -- //David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // [quoted text, click to view] "Chris Kane" <ChrisKane@discussions.microsoft.com> wrote in message We have written a class that enumerates the items in a WSS list and thennews:3DA9A3DB-FD45-436E-99B5-265B002F81B3@microsoft.com... attemptes to open the attachment for each item. We have written two classes, one to impersonate a user and read in the list information and the other to be called by the first which actually opens the attachment. Our code fails when it tries to open the attachment in the second class with a 401 - Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. What's strange is that I can use IE to open the URL to the attachemnt without any problems. I noticed in the IIS logs that when I open the URL, I can see the domain\password passed to IIS from IE. However, when our code tries to access the same URL, no user information is passed, causing the 401. We have impersonated a valid user in our code, so why does IIS not see it? Thanks!
hi
i think the current context is associated with current logged in user credentials so change the context. string CurrentSiteUrl = SPControl.GetContextWeb(Context).Url; start impersonation//username password etc SPSite tmpSite = new SPSite(CurrentSiteUrl); tmpSite.CatchAccessDeniedException = false; SPWeb mysite= tmpSite.OpenWeb(); SPList lists=mysite.Lists["list name"]; undo impersonation hope this helps bart [quoted text, click to view] "Mike Walsh" wrote:
> Please do not post WSS programming questions in future to the main WSS > newsgroup but only to the newsgroup specially created for WSS programming > questions. > > We are maintaining a clear split where WSS Programming questions go only to > microsoft.public.sharepoint.windowsservices.development and not to the > (Administration issues) main newsgroup > microsoft.public.sharepoint.windowsservices. > > This split is to the benefit of the readers of one or both these newsgroups. > > Thanks. > > Mike Walsh, Helsinki, Finland > WSS FAQ at http://wss.collutions.com > Please reply to the newsgroup > > "Chris Kane" <ChrisKane@discussions.microsoft.com> wrote in message > news:3DA9A3DB-FD45-436E-99B5-265B002F81B3@microsoft.com... > > We have written a class that enumerates the items in a WSS list and then > > attemptes to open the attachment for each item. We have written two > > classes, > > one to impersonate a user and read in the list information and the other > > to > > be called by the first which actually opens the attachment. Our code > > fails > > when it tries to open the attachment in the second class with a 401 - > > Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. > > What's > > strange is that I can use IE to open the URL to the attachemnt without any > > problems. I noticed in the IIS logs that when I open the URL, I can see > > the > > domain\password passed to IIS from IE. However, when our code tries to > > access the same URL, no user information is passed, causing the 401. We > > have > > impersonated a valid user in our code, so why does IIS not see it? > > > > Thanks! > >
Okay, thanks. We store XML documents as SPListItem attachments that are to
be processed by our workflow application. We attempted to pass the attachment's URI directly to the XPathDocument class constructor in preparation for transforming it via XSL. This is where we originally received the 401 from IIS. I can see how we could retrieve the attachemnt using the HTTPWebResponse object and then pass this into the XPathDocument class as a stream. Is this the best way to do this? Thanks for your help! [quoted text, click to view] "David Wang [Msft]" wrote:
> IIS does not see your impersonated user because you failed to authenticate > as that user. > > Remember that we are talking about HTTP, which has its own publicly defined > authentication protocols. Client-side impersonation isn't one of them. The > identity of the user on the client, impersonated or not, means ABSOLUTELY > NOTHING on the server unless you negotiate HTTP authentication of some sort. > > IE, for example, does this authentication behind the scenes without you > noticing. So do many of the Windows programs and protocols. This isn't how > the web and HTTP works, though, and you just have to follow the rules. > > -- > //David > IIS > http://blogs.msdn.com/David.Wang > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "Chris Kane" <ChrisKane@discussions.microsoft.com> wrote in message > news:3DA9A3DB-FD45-436E-99B5-265B002F81B3@microsoft.com... > We have written a class that enumerates the items in a WSS list and then > attemptes to open the attachment for each item. We have written two > classes, > one to impersonate a user and read in the list information and the other to > be called by the first which actually opens the attachment. Our code fails > when it tries to open the attachment in the second class with a 401 - > Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. What's > strange is that I can use IE to open the URL to the attachemnt without any > problems. I noticed in the IIS logs that when I open the URL, I can see the > domain\password passed to IIS from IE. However, when our code tries to > access the same URL, no user information is passed, causing the 401. We > have > impersonated a valid user in our code, so why does IIS not see it? > > Thanks! > >
Chris,
This sounds like a good approach. If you use the WebRequest be sure to set it's credentials. Alternatively, a better way may be to get the SPFile object of the ListItem. I do this in my PortalTools project in creating a disk based package of document libraries (url is below). Daniel Larson http://www.portalbuilder.org http://workspaces.gotdotnet.com/portaltools [quoted text, click to view] "Chris Kane" wrote:
> Okay, thanks. We store XML documents as SPListItem attachments that are to > be processed by our workflow application. We attempted to pass the > attachment's URI directly to the XPathDocument class constructor in > preparation for transforming it via XSL. This is where we originally > received the 401 from IIS. I can see how we could retrieve the attachemnt > using the HTTPWebResponse object and then pass this into the XPathDocument > class as a stream. Is this the best way to do this? > > Thanks for your help! > > "David Wang [Msft]" wrote: > > > IIS does not see your impersonated user because you failed to authenticate > > as that user. > > > > Remember that we are talking about HTTP, which has its own publicly defined > > authentication protocols. Client-side impersonation isn't one of them. The > > identity of the user on the client, impersonated or not, means ABSOLUTELY > > NOTHING on the server unless you negotiate HTTP authentication of some sort. > > > > IE, for example, does this authentication behind the scenes without you > > noticing. So do many of the Windows programs and protocols. This isn't how > > the web and HTTP works, though, and you just have to follow the rules. > > > > -- > > //David > > IIS > > http://blogs.msdn.com/David.Wang > > This posting is provided "AS IS" with no warranties, and confers no rights. > > // > > "Chris Kane" <ChrisKane@discussions.microsoft.com> wrote in message > > news:3DA9A3DB-FD45-436E-99B5-265B002F81B3@microsoft.com... > > We have written a class that enumerates the items in a WSS list and then > > attemptes to open the attachment for each item. We have written two > > classes, > > one to impersonate a user and read in the list information and the other to > > be called by the first which actually opens the attachment. Our code fails > > when it tries to open the attachment in the second class with a 401 - > > Unauthorized error from IIS on http://localhost/_vti_bin/owssrv.dll. What's > > strange is that I can use IE to open the URL to the attachemnt without any > > problems. I noticed in the IIS logs that when I open the URL, I can see the > > domain\password passed to IIS from IE. However, when our code tries to > > access the same URL, no user information is passed, causing the 401. We > > have > > impersonated a valid user in our code, so why does IIS not see it? > > > > Thanks! > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |