Obteniendo el usuario registrado por el usuario, dado el SPWEB, independientemente de los privilegios elevados

Question

Tengo un requisito para poder obtener siempre el usuario registrado.

El objeto que pasará el proceso de llamada es el SPWEB.

Como este es un código heredado, no puedo cambiar de qué se envían los procesos de llamadas, y aquí está el problema: Algunos de ellos pasan en la SPWEB que se ejecutan como es, y algunos envían en un SPWEB que se encuentra en privilegios elevados.Para los elevados privelegios, el usuario registrado se devuelve como sistema.

En ambos casos, quiero obtener el usuario que ha iniciado sesión actual.

es esto en absoluto posible?

Answer 1

Tienes dos situaciones posibles aquí.

no se elevará, por lo que puede obtener su usuario desde allí.

Case B: Tu método se llama dentro de un delegado de rendimiento de ejecución de impliviles En este caso, recrear la instancia SPWEB, no lo hará bien. Cualquier nueva instancia todavía estaría elevada, por lo que esto es un no ir. Para escapar de esta situación, debe encontrar una instancia que se creó fuera del alcance de la elevación. ¿Cómo? Al explotar su contexto de ejecución: por ejemplo, en un receptor de eventos de características, podría acceder a la instancia web en las propiedades del evento, etc. Dado que está en un método personalizado y no puede alterar los parámetros recibidos, debe acceder a algún tipo de contexto. ¿Podrías recurrir a Spcontext.current.web? Ese instancia no está elevada, por lo que el usuario debe ser el actual que navega por el sitio. Dicho esto, puede estar en una situación en la que el contexto no sea válido / nulo, en cuyo caso AFAIK no hay forma de obtener el usuario original de la instancia elevada: deberá almacenarlo en alguna parte (consejo: un Singleton estático?) Antes de ingresar al contexto de elevación.

---

editar

¿Qué hacer si su método se llama dentro de un delegado de PRIVIMIENTO DE ERRORWELTELEVIGHTES, ¡pero no está seguro de tener un SPCONTEXT válido? Esto es solo una conjetura muy salvaje, pero pensemos en ello. RunwithelEvatedPrivileges volverá a la identidad de la aplicación de la aplicación, ¿verdad? Si no hay un grupo de aplicaciones, significaría que no existe una identidad de la piscina de aplicaciones, por lo que el usuario actual afuera y dentro del delegado debe ser el mismo. Si hay un grupo de aplicaciones, la mayoría de las veces tendrás un SPContex, que se desevaliza por definición. También hay algún caso específico en el que se ejecuta en trabajos de temporizador y, como el contexto y , en ese caso, creo que está utilizando la identidad de la piscina de la aplicación de todos modos, así que nuevamente, se ejecuta con elevado debería tener Sin efecto.

Basado en esto, parece que su mejor apuesta es usar al usuario desde el SPCONTEX cuando sea posible, y asuma que el usuario elevado e inellevado sea el mismo cuando el contexto es nulo. Tome eso con un grano de sal, aunque ...

Answer 2

A medida que Fazio declaró que el desarrollador originario que hizo que el código de la lagacidad debería de la impersonación utilizada para pasar el objeto SPWEB, pero en su caso, ¡no puedes!

Elevación significa que su objeto SPWEB está elevado al usuario del sistema y devolverá ese usuario independientemente hasta que se deseche el objeto SPWEB.

SPUser loggedinUser = SPContext.Current.Web.CurrentUser;

El código anterior funcionaría si está fuera del objeto SPWEB elevado, pero si está dentro del bloque elevado, ¡devolverá la cuenta del sistema desafortunadamente!

¿Puedes publicar algún código?¿O darnos una mayor información sobre dónde va a usar el objeto SPWEB que se pasa?¿Tal vez pueda usar el código anterior en el objeto SPWEB abierto actual y luego configure el objeto SPWEB al objeto elevado?

Pero la respuesta corta no es que no pueda obtener el usuario realizado real de un usuario elevado!