Use runwithelevatedprivileges to simulate the administrator privilege and use spcontext with caution.

In WSS 3.0, we use:

 
Spsecurity. runwithelevatedprivileges (Delegate(){// Implementation Details omitted});
 

Can be upgradedCodeTo simulate the Administrator identity.

Do not use spcontext in runwithelevatedprivileges. current. web, spcontext. current. site, spcontrol. getcontextweb (httpcontext. current) and so on. Get the current web or site based on the current context, and get all the objects based on these methods (including the list, listitem, and other objects based on these objects) all operations are based on the current website login user permissions. Even in runwithelevatedprivileges, their operation permissions are not administrator.

Therefore, if you want to allow the code in runwithelevatedprivileges to operate normally as an administrator, you must reinitialize the corresponding object, for example:

 
Spsecurity. runwithelevatedprivileges (Delegate(){Using(Spsite mysite =NewSpsite (spcontext. Current. Site. url) {response. Write (mysite. rootweb. currentuser. loginname );}});
 

 
The above mysite. rootweb. currentuser. loginname returns the Administrator's Logon account.
 

However, if spcontext is used as described earlier:
 

 
Spsecurity. runwithelevatedprivileges (Delegate() {Response. Write (spcontext. Current. Web. currentuser. loginname );});
 

At this time, even if the account is running within the range of elevation of permissions, the account name for logon to the current website is obtained, rather than the administrator account.