Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Impersonation Event Handler - Modified By

  Asked By: Nicholas    Date: May 13    Category: Sharepoint    Views: 2268

I am having some issues with event handling. I am trying to get the original authenticated user to show up as the "Modified By" user rather than the app pool account. I have tried "undo-ing" the impersonation earlier, but if I exclude specific instantiations, then eventhandling errors out. I've scoured the blogs in trying to understand this, but haven't found anything definitive. I'm tending to feel that the app pool account needs to be impersonated until the ListItem.Update is called, which is obviously too late.

Is there a way to programmatically cause a secondary action afterwards to update a value with an existing value impersonating the original authenticated user, so that the "Modified By" would be changed in that regard? This sounds very hokey, but I'm running out of ideas.



7 Answers Found

Answer #1    Answered By: Laura Walker     Answered On: May 13

Just a guess, but if you are running  a synchronous event  receiver (one
ending in "ing"), the currently authenticated  user's credentials are
used (or at least available). If you are running a post asynchronous
event receiver (one ending in "ed"), the user  that caused the event is
only available as properties metadata. The post asynchronous event is
run by the application pool  in a different security context.

Answer #2    Answered By: Percy Beach     Answered On: May 13

However, I am not sure which event  receiver that falls under, but when I looked at the code I am capturing the "Insert" event:

if (listEvent.Type == SPListEventType.Insert )

I am guessing this is an asynchronous event? If that is the case, is there a way to programmatically  to follow this asynchronous event with a synchronous event. My hopes is just to have this Modified By column to reflect the authenticated  user rather than the app  pool, if i can programmatically make an update  where a column is updated with the same value, that would be fine, since it would all occurs at the same time frame.

Any thoughts?

Answer #3    Answered By: Christop Mcfadden     Answered On: May 13

In WSS v2, there are only post asynchronous event  handlers.

In WSS v3, there are some synchronous pre-event handlers; they all end
in "ing". All post asynchronous events end in "ed".

Not sure how you can change the person that modified  a list item, that
may be a read only field.

Otherwise, I could write code that said that you modified something that
you hadn't even touched. That would be an auditing breach.

Answer #4    Answered By: Kundan Jambhale     Answered On: May 13

I am using WSS v2, and yes I do believe Modified By is a read only field (I've tried to set it during impersonation, but it errors), which was why I asking if there was a way to revert to impersonating the user  who caused the event  and firing another event that would allow for a correct impersonation  of the item added.

As for audit breach concerns, I would think that if a user uploaded a number of items and all that is reported is the app  pool id, that would constitute an audit breach since I cannot resolve who actually uploaded the items, and since the point of the code is to show  user resolution, I could document the process to show why the user acct is involved.

Answer #5    Answered By: Alyssa Butler     Answered On: May 13

What does the Created By column show?????????

Answer #6    Answered By: Katy Patton     Answered On: May 13

Created By shows the correct authenticated  user. This is because, the eventhandler for ItemType.Insert is actually fired after the Insert already takes place, so the created was already done before impersonation  of the app  pool was done. This is good, but it is a bit confusing to the users when they see some service account  as the last modified. I went ahead and created another column and put in the username as the Last modified  By column, but it can easily be modified by the user, and would require me to code an event  handle for every event to keep it in sync.

Answer #7    Answered By: Ana Payne     Answered On: May 13

I think that the product team would say that this is
working as designed. The user  that created the document is correctly
captured as is the subsequent system account  that modified  the list

I would imagine that impersonation  doesn't work for you because you
don't know the user's password. If you did, I would think that would be
a viable alternative to showing the Application Pool identity.

Didn't find what you were looking for? Find more on Impersonation Event Handler - Modified By Or get search suggestion and latest updates.