|
|
You're in the
dotnet security
group:sharepoint - impersonating the authenticated user.
dotnet security:
When the ASP.NET Worker Process starts a Web application, the Web application inherits the identity of this worker process (Network Service by default), or if impersonation is enabled, the Web application runs under the user account that is authenticated by IIS, or the user account that is configured in the Web.config file. Fine. A document event handler however isn't a web application, it is a class library used by a web application, (which can be identified within the MSSharePointPortalAppPool application pool). Consequently the authenticated token doesn't get passed to it, and it runs under the application pool identity instead. Impersonation is still possible within the event handler, but it has to be explicitly legislated for at a code-level, by invoking the (unmanaged) LogonUser(). Implementation of this strategy for a specified user is well documented, both within MSDN and outside, but I have found no documentation on how to get hold of the impersonated/authenticated token WITHIN THE EVENT HANDLER ITSELF. One workaround that i have played with is to use SSO to take the user to the SSO logon form the first time the event is triggered, but the call to GetCredentialEntryUrl() fails. Can it only be called from within a web part? If not, is there another way to retrieve the authenticated token from within the event handler?
There is not. The token is destroyed by the time the event assembly thread
spins up Just wondering, why do you need to run the event assembly in the user context? You should have access to anything you may need since it runs in the context of the Sharepoint admin account. -Brad [quoted text, click to view] "Tamim Sadikli" <TamimSadikli@discussions.microsoft.com> wrote in message application inherits the identity of this worker process (Network Service bynews:06D69FC7-73FD-43CC-86DD-ED676AEBB77B@microsoft.com... > Under IIS 6.0, ASP.NET Web applications run inside the ASP.NET Worker Process (aspnet_wp.exe). > > When the ASP.NET Worker Process starts a Web application, the Web default), or if impersonation is enabled, the Web application runs under the user account that is authenticated by IIS, or the user account that is configured in the Web.config file. Fine. [quoted text, click to view] > library used by a web application, (which can be identified within the> A document event handler however isn't a web application, it is a class MSSharePointPortalAppPool application pool). Consequently the authenticated token doesn't get passed to it, and it runs under the application pool identity instead. [quoted text, click to view] > explicitly legislated for at a code-level, by invoking the (unmanaged)> Impersonation is still possible within the event handler, but it has to be LogonUser(). Implementation of this strategy for a specified user is well documented, both within MSDN and outside, but I have found no documentation on how to get hold of the impersonated/authenticated token WITHIN THE EVENT HANDLER ITSELF. [quoted text, click to view] > the SSO logon form the first time the event is triggered, but the call to> One workaround that i have played with is to use SSO to take the user to GetCredentialEntryUrl() fails. Can it only be called from within a web part? If not, is there another way to retrieve the authenticated token from within the event handler? [quoted text, click to view] >
Hi Brad,
You asked: 'why do you need to run the event assembly in the user [quoted text, click to view] > context? A) I've written a document event handler to move documents around within a document library, based on the value which a particular property (e.g. DestFolder) is set to. It works just fine. However because it runs in the context of the application pool identity, the 'Modified By' field is set to this account once the document has moved folders, and I want it to be set to the UserName of the user who caused the move, i.e. who set the doc. property - i.e. the authenticated user. SSO was a dead-end because I'm dealing with a sharepoint site, not a portal site. If you could suggest an alternative that would be wonderful. Tamim. [quoted text, click to view] "Brad Smith [MVP]" wrote:
> There is not. The token is destroyed by the time the event assembly thread > spins up > Just wondering, why do you need to run the event assembly in the user > context? You should have access to anything you may need since it runs in > the context of the Sharepoint admin account. > > -Brad > > "Tamim Sadikli" <TamimSadikli@discussions.microsoft.com> wrote in message > news:06D69FC7-73FD-43CC-86DD-ED676AEBB77B@microsoft.com... > > Under IIS 6.0, ASP.NET Web applications run inside the ASP.NET Worker > Process (aspnet_wp.exe). > > > > When the ASP.NET Worker Process starts a Web application, the Web > application inherits the identity of this worker process (Network Service by > default), or if impersonation is enabled, the Web application runs under the > user account that is authenticated by IIS, or the user account that is > configured in the Web.config file. Fine. > > > > A document event handler however isn't a web application, it is a class > library used by a web application, (which can be identified within the > MSSharePointPortalAppPool application pool). Consequently the authenticated > token doesn't get passed to it, and it runs under the application pool > identity instead. > > > > Impersonation is still possible within the event handler, but it has to be > explicitly legislated for at a code-level, by invoking the (unmanaged) > LogonUser(). Implementation of this strategy for a specified user is well > documented, both within MSDN and outside, but I have found no documentation > on how to get hold of the impersonated/authenticated token WITHIN THE EVENT > HANDLER ITSELF. > > > > One workaround that i have played with is to use SSO to take the user to > the SSO logon form the first time the event is triggered, but the call to > GetCredentialEntryUrl() fails. Can it only be called from within a web part? > If not, is there another way to retrieve the authenticated token from within > the event handler? > > > >
I would suggest trying to assign the Modified By field in the assebly to the
user information that is passed with the event. It may be read-only, I know some of the meta fields are, but you should give it a shot. If that doesn't work, create new Modified By field and do the assignment manually on every event. -Brad [quoted text, click to view] "Tamim Sadikli" <TamimSadikli@discussions.microsoft.com> wrote in message document library, based on the value which a particular property (e.g.news:46664592-3BEA-47F8-BE7A-2115C0F05FF8@microsoft.com... > Hi Brad, > > You asked: 'why do you need to run the event assembly in the user > > context? > > A) I've written a document event handler to move documents around within a DestFolder) is set to. It works just fine. However because it runs in the context of the application pool identity, the 'Modified By' field is set to this account once the document has moved folders, and I want it to be set to the UserName of the user who caused the move, i.e. who set the doc. property - i.e. the authenticated user. [quoted text, click to view] > > SSO was a dead-end because I'm dealing with a sharepoint site, not a portal site. If you could suggest an alternative that would be wonderful. > > Tamim. > > > "Brad Smith [MVP]" wrote: > > > There is not. The token is destroyed by the time the event assembly thread > > spins up > > Just wondering, why do you need to run the event assembly in the user > > context? You should have access to anything you may need since it runs in > > the context of the Sharepoint admin account. > > > > -Brad > > > > "Tamim Sadikli" <TamimSadikli@discussions.microsoft.com> wrote in message > > news:06D69FC7-73FD-43CC-86DD-ED676AEBB77B@microsoft.com... > > > Under IIS 6.0, ASP.NET Web applications run inside the ASP.NET Worker > > Process (aspnet_wp.exe). > > > > > > When the ASP.NET Worker Process starts a Web application, the Web > > application inherits the identity of this worker process (Network Service by > > default), or if impersonation is enabled, the Web application runs under the > > user account that is authenticated by IIS, or the user account that is > > configured in the Web.config file. Fine. > > > > > > A document event handler however isn't a web application, it is a class > > library used by a web application, (which can be identified within the > > MSSharePointPortalAppPool application pool). Consequently the authenticated > > token doesn't get passed to it, and it runs under the application pool > > identity instead. > > > > > > Impersonation is still possible within the event handler, but it has to be > > explicitly legislated for at a code-level, by invoking the (unmanaged) > > LogonUser(). Implementation of this strategy for a specified user is well > > documented, both within MSDN and outside, but I have found no documentation > > on how to get hold of the impersonated/authenticated token WITHIN THE EVENT > > HANDLER ITSELF. > > > > > > One workaround that i have played with is to use SSO to take the user to > > the SSO logon form the first time the event is triggered, but the call to > > GetCredentialEntryUrl() fails. Can it only be called from within a web part? > > If not, is there another way to retrieve the authenticated token from within > > the event handler? > > > > > > > > >
Don't see what you're looking for? Try a search.
|
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
| home · blog · groups | Questions? Comments? Contact the dn |