NOTA: Aunque esta serie está dirigida a pequeños desarrolladores de juegos, es igualmente aplicable a cualquier persona que desee aprender a utilizar LightSwitch.
En miramos la justificación del uso de LightSwitch como un servidor de datos de juego y cómo configurar y publicar un proyecto LightSwitch en Windows Azure (opcional). En esta parte, vamos a ver el trabajo del lado del servidor necesaria para permitir a los usuarios crear sus propias cuentas en la red de juego. Vamos a echar un vistazo a varias muestras del lado del cliente para registrarse e iniciar sesión en la parte 3 para completar el proceso de extremo a extremo.
En este artículo, usted aprenderá:
- Lo OData es, cómo funciona y los mensajes HTTP subyacentes que utiliza
que preocuparse por la mayoría de estos detalles internos, y no vamos a construir las peticiones y las respuestas a mano. Todo esto es sólo para mostrar cómo funciona bajo el capó. En los ejemplos a continuación, pensar en Hurl (o cualquier otra herramienta que se use) como una simulación del código de cliente escribiremos más adelante; no tenemos un cliente (juego) en el momento, por lo que sólo tiene que utilizar estas herramientas en lugar de HTTP para los propósitos de prueba, pero si uno se imagina la herramienta como el juego en sí, puede ayudar a visualizar y comprender lo que estamos tratando de cumplir mejor. Gestión de usuarios en una aplicación LightSwitch Hasta ahora hemos hablado de cómo realizar consultas (leer) y añadir filas a una tabla existente en nuestra aplicación, y haciendo esto siempre nos ha requerido para iniciar la sesión como un usuario autenticado LightSwitch. Si ha seguido la parte 1, tendrá un proyecto implementado con un solo usuario, probablemente llamada admin. Nosotros queremos que nuestros jugadores sean capaces de iniciar sesión en la aplicación LightSwitch como a sí mismos y tienen acceso de lectura / escritura a supropios perfiles, acceso de lectura a las tablas de clasificación y una cierta cantidad de permisos de escritura en las tablas de clasificación y algunas otras tablas dependiendo del juego. Por tanto, necesitamos una manera de acceder a la base de datos de usuario LightSwitch real y añadir nuevos usuarios. Pero primero tenemos que comprender cómo los usuarios están organizados en una aplicación LightSwitch. La base de datos de usuario LightSwitch contiene cinco tablas denominadas UserRegistrations, Roles, RoleAssignments, Permisos y RolePermissions. Aquí es lo que son para: la tabla UserRegistrations define nombre de usuario y contraseña (credenciales de acceso) la tabla de permisos es una tabla de sólo lectura que define nombres para cada acción permitida específica que haya definido en el proyecto LightSwitch de cada usuario (se puede escribir en el cuadro X , se puede leer de la mesa Y, etc.) funciones de la tabla se definen los nombres de los roles, que son grupos de permisos de la tabla RolePermissions define qué permisos están en la cual los papeles de la mesa RoleAssignments define qué usuarios son miembros de los cuales los roles que esto suenamás complicado de lo que es, así que vamos a ilustrar con un ejemplo: ¿Quieres dos tipos de usuarios: los jugadores que saben leer y escribir su propio perfil de usuario, leer el perfil de usuario de otra persona, leer las tablas de clasificación y escribir una nueva fila a la tabla de líderes, pero nada más. El otro tipo de usuario será una GameManager que es un empleado de su empresa que gestiona el servidor de juego. Estos usuarios pueden hacer todo lo que los jugadores pueden, pero también pueden leer y escribir perfiles de nadie (para eliminar el contenido ofensivo), eliminar los perfiles de usuarios (BAN), y editar cualquier cosa en las tablas de clasificación (para eliminar los tramposos). Esto se organiza de la siguiente manera: Crear dos papeles llamados GameManager y jugador. Éstas van en la tabla de funciones. Esto se hace más fácilmente desde la interfaz de gestión de usuarios (ver siguiente sección) Crear permisos llamados CanReadLeaderboards, CanEditLeaderboards, CanAddNewScore, CanReadAllProfiles, CanWriteOwnProfile, CanWriteAllProfiles y CanDeleteProfiles. Éstas van en la tabla de permisos. Túhacerlo desde dentro del IDE LightSwitch en Visual Studio sí. Tenga en cuenta que para hacer los permisos realmente hacen algo (en vigor), el código tiene que ser añadido a cada mesa para hacerlas cumplir; esto se discute más adelante Asignar permisos a los roles. Esto se hace en la tabla RolePermissions y está de nuevo logra más fácilmente a través de la interfaz de gestión de usuarios. Para el papel del jugador, añadiremos CanReadLeaderboards, CanAddNewScore, CanReadAllProfiles y CanWriteOwnProfile como los permisos asignados a esta función. Para el papel GameManager, añadiremos CanEditLeaderboards, CanWriteAllProfiles y CanDeleteProfiles. Cuando se crea un usuario, su nombre de usuario y contraseña entrarán en UserRegistrations. Mediante la adición de código del lado del servidor para el proyecto LightSwitch en Visual Studio, vamos a garantizar que las nuevas cuentas tienen automáticamente una entrada para ellos agregados en RoleAssignments asignarlos a la función del jugador. Es muy importante hacer esto sólo con el código del lado del servidor. Si permite que el código del lado del cliente para establecer elEl papel del usuario, que podría hackear el código, cambie el papel de GameManager, crear un nuevo usuario y, esencialmente, lograr un corte de elevación de privilegios que les permitirá suprimir los perfiles y desordenar las tablas de clasificación de todos. Si vas a empezar a sudar, no se preocupe! Vamos a ir sobre cómo hacer todas estas cosas con ejemplos paso a paso a lo largo de esta serie! Creación de una interfaz de gestión para su aplicación LightSwitch El IDE LightSwitch no nos permite editar la base de datos de usuario durante el desarrollo o despliegue, y el cliente HTML tampoco proporciona ninguna interfaz para los administradores. Sin duda, sería más bien incómodo tener que utilizar una herramienta como Hurl para configurar todos los usuarios por defecto, los permisos y papeles pero afortunadamente hay una solución. Al crear un cliente de escritorio para nuestra aplicación LightSwitch, podemos acceder a la interfaz de administración que nos permite editar la base de datos de usuario. Figura 2. Configuración de las propiedades del cliente de escritorio para crear un escritorio de WindowsPara añadir esta aplicación a su proyecto de la parte 1 de esta serie, siga estos pasos: Figura 3. LightSwitch ventana del cliente de escritorio del usuario de administración de base de datos Haga clic en el proyecto GameNetwork en el Explorador de soluciones y seleccione Agregar cliente ... Haga clic en el menú de cliente de escritorio, licencia el nombre predeterminado (DesktopClient) y haga clic en OK Haga clic en DesktopClient en el Explorador de soluciones y seleccione Propiedades en el menú Seleccione la pestaña Tipo de cliente y cambiar la opción de cliente de web de escritorio. Esto hará que un archivo EXE descargable que se produce, que es una aplicación de Windows que puede utilizar para conectarse a la base de datos y administrar LightSwitch desde su escritorio (ver Figura 2). Cierre la ventana Propiedades elija Generar -> Publicar GameNetwork desde la barra de menú principal Ahora tendrá que navegar a la pestaña Firma Digital en la sección Configuración de seguridad del cuadro de diálogo Configuración de publicación (que se resaltará con un signo de exclamación) y seleccione un certificado . Simplemente elija su Windows Azure publicarpresentar credenciales aquí - que ya debería estar en la lista desplegable. Haga clic en Siguiente y publicar luego esperar un par de minutos Vaya a yourwebsite.com/DesktopClient/ y una vez que las cargas de Silverlight, se le pedirá para descargar e instalar la aplicación. Haga clic en el botón y utilice los Más opciones desplegables para decidir dónde quiere que se instalarán los accesos directos a aplicaciones (de escritorio y / o el menú Inicio). Una vez que la aplicación se ha instalado, ponerlo en marcha y se le presentará con una pantalla de inicio de sesión estándar. Inicie la sesión como un administrador. Ahora debería estar en la ventana de administración. Si hace clic en el menú Administración de la barra en la parte superior, se puede elegir Roles y Usuarios y podrá ver pantallas similares a la figura 3. Ahora puede editar la base de datos de usuario como desee. Recuerde que aunque se puede agregar permisos aquí, usted puede y debe hacerlo con preferencia en el IDE de Visual Studio LightSwitch de modo que los nombres de permisos pueden ser referenciados en el código del lado del servidor. Vendremosde nuevo a esta interfaz y añadir cosas como y cuando los necesitamos, pero ahora vamos a seguir adelante y mirar tres maneras de agregar usuarios mediante programación (y asignarlos a los papeles), cada uno con sus propias ventajas y desventajas. 1. Acceso a la base de datos de usuario directamente como un administrador LightSwitch proporciona un punto final que nos permite consultar y modificar la base de datos de usuario llamada Microsoft.LightSwitch.SecurityData.svc. Funciona de la siguiente manera: Si ha iniciado sesión como administrador, puede leer y escribir todos los datos del usuario. Si está en el sistema como un usuario sin privilegios de administrador, sólo se puede ver (leer) sus propios datos del usuario y no se puede escribir ningún dato. Es decir, si intenta consultar la tabla de usuario a buscar todos los nombres de usuario y contraseñas, sólo recuperar su cuenta. Esto es por razones obvias de seguridad. El uso de Hurl u otra herramienta HTTP podemos añadir un usuario mediante la publicación de algunos datos para Microsoft.LightSwitch.SecurityData.svc / UserRegistrations de la siguiente manera: TargetAhora volver a publicar el proyecto para que se añade el permiso para la base de datos. Para editar usuarios y roles, se utiliza el cliente de escritorio se discutió anteriormente. Abra el cliente de escritorio (GameNetwork en el menú de Inicio de Windows). Abra la Administración -> menú de funciones y crear una nueva función llamada UserRegistrant. Añadir el permiso CanAddUsers a la función (que se muestra en los permisos panel usando el nombre de visualización que ha seleccionado en las propiedades del proyecto cuando se crea el permiso). Esto establece el papel. Ahora abre la Administración -> menú de usuario y crear un nuevo usuario llamado __userRegistrant, con el __userRegistrant contraseña, haga clic en el icono en la sección Roles y añadir el papel UserRegistrant. Por último, haga clic en Guardar. Las fichas Usuarios y Roles debería verse como se muestra en las figuras 8 y 9: Figura 8. Añadiendo el usuario __userRegistrant y asignándole al papel UserRegistrant Figura 9. Configuración del papel UserRegistrant aplicar los permisos Ahora sólo tenemos que hacer cumplir el permiso CanAddUsers. EnLightSwitch su proyecto, haga doble clic en el servidor -> UserRegistrationService -> UserRegistrationViews tabla en el Explorador de soluciones (la tabla de origen de datos de WCF Servicio RIA). Seleccione la flecha al lado de escribir código de la barra de herramientas Diseñador y elija el método UserRegistrationViews_CanInsert en la sección Métodos de control de acceso. Visual Studio creará una nueva función en la que se puede asignar un valor booleano para el resultado variable, lo que indica al interruptor de la luz si se le permitirá al usuario que actúa para llevar a cabo una operación de inserción o no. Este método se llama cuando un usuario intenta insertar algo en la tabla UserRegistrationViews, antes de realizar la inserción. Si el resultado se establece en false, se le denegará el intento de insertar datos. El código es muy simple y se ve así: UserRegistrationViews_CanInsert vacío parcial (ref resultado bool) { Resultado = Application.Current.User.HasPermission (Permissions.CanAddUsers); } La función devuelve verdadero si Application.Current.User.HasPermissionel usuario actual tiene el permiso especificado, por lo que esta verificación se asegurará de que sólo los usuarios con CanAddUsers (es decir. Sólo __userRegistrant) se le permitirá insertar datos. También tenemos que permitir que __userRegistrant va a escribir en SecurityData.UserRegistrations. Dado que las cuentas de administrador sólo se les permite hacer esto, utilizamos una técnica llamada de elevación de privilegios para dar temporalmente los permisos de administrador __userRegistrant durante la duración de la llamada al servicio WCF RIA. Una vez que termina la llamada, los permisos elevados son revocados. Elija el Código de escritura desplegable de nuevo y esta vez seleccione UserRegistrationViews_Inserting. Esta función es llamada después de UserRegistrationViews_CanInsert, después de la inserción se ha permitido, pero antes de que realmente se lleva a cabo. Aquí podemos renunciar temporalmente privilegios de administrador __userRegistrant de la siguiente manera: UserRegistrationViews_Inserting vacío parcial (entidad UserRegistrationView) { Application.Current.User.AddPermissions (Permissions.SecurityAdministration); }Una vez más, tan pronto como se haya completado la inserción, los permisos añadidos aquí se ha revocado, por lo que este no es un cambio permanente. Ahora debemos estar en el negocio! Volver a publicar su proyecto y repita la prueba de HTTP se muestra en la Figura 6. Usted debe encontrar que el __userRegistrant cuenta con __userRegistrant contraseña puede agregar nuevas cuentas, pero ninguna otra cuenta, incluyendo los que se crean y ADMIN sí mismo puede agregar usuarios (si quieres las cuentas de administrador para poder agregar usuarios, añadir CanAddUsers a la función de administrador en el cliente de escritorio). Límite que puede leer los perfiles de usuario En este momento, cualquier usuario conectado puede leer toda la tabla UserRegistrationViews (a excepción de las contraseñas). A veces esto puede ser lo que quiera, pero por lo general no. especialmente nosotros NO la gente sea capaz de leer direcciones de correo electrónico de otros usuarios oa otros detalles personales, de contacto o de pago. Afortunadamente, es fácil para restringir UserRegistrationViews de tal manera que el usuario conectado sólo puede tener acceso a su propio perfil. Basta con añadir una línea de código enEl método de RIA su Servicio WCF y GetUsers () volver a publicar el proyecto: volver (de usuario en usuarios donde user.username == ApplicationProvider.Current.User.Name seleccione nuevo UserRegistrationView { Nombre de usuario = user.username, Password = user.password, NombreCompleto = user.FullName, Email = (de perfil en this.Context.UserProfiles donde profile.UserName == user.username seleccione profile.Email) .FirstOrDefault () }); La cláusula where modifica el resultado de la consulta de tal manera que sólo las filas que coinciden con el nombre del usuario conectado actualmente se devuelven, en esencia, lo que significa que sólo una fila - se mostrará - la fila del usuario actual. Si visitas ahora UserRegistrationService.svc / UserRegistrationViews / en su navegador como un usuario conectado, se mostrarán los datos del perfil que solamente los usuarios. Resumen En este punto, tenemos: un servicio que nos permite insertar y seleccionar datos desde / hasta tantonuestra mesa y SecurityData.UserRegistrations en un paso de acceso restringido de tal manera que sólo el usuario invitado puede agregar nuevas cuentas a través de este servicio UserProfiles acceso restringido de tal forma que los usuarios sólo pueden acceder a sus propios perfiles eliminan la necesidad de que el cliente para conocer la contraseña de administrador o tiene administrador privilegios de ninguna duplicación innecesaria de datos entre tablas y todo funciona bastante bien. Uso del servicio de WCF RIA nos evita el problema devastador de la necesidad de suministrar la contraseña de administrador a los usuarios que el método 1 sufriese y resuelve el problema de la atomicidad de utilizar UserProfiles y SecurityData.UserRegistrations al mismo tiempo, lo que nos permite almacenar más datos para cada usuario de los campos predeterminados proporcionados por SecurityData.UserRegistrations. IMPORTANTE: Un problema de seguridad a tener en cuenta es que no hemos conseguido la tabla UserProfiles sea leída o escrita directamente, por lo que los usuarios maliciosos todavía podemos utilizar esto como una puerta trasera para robar direcciones de correo electrónico de todo el mundo y todo lootros datos que almacene allí, o modificarlo. Esto debe ser abordado en un servidor de producción. Hay algunas desventajas, sin embargo: Las porciones de código repetitivo Cada vez que los campos en una de las mesas de cambio, usted tiene que cambiar la clase de proxy que definió en sus fuentes de proyecto fuentes de código de datos de WCF RIA de WCF RIA Services no se pueden editar en el Diseñador LightSwitch (a excepción de unas pocas propiedades) Asegurar que todo está seguro puede resultar engorroso ¿no sería bueno si pudiéramos acabar con servicios WCF RIA por completo, y generar automáticamente los nuevos usuarios en SecurityData.UserRegistrations cuando se añade una nueva fila a ¿Perfiles de usuario? También estamos todavía a abordar la cuestión de la asignación automática de nuevos usuarios a las funciones cuando se crean, por lo que tenemos que ver en eso también. 3. La generación de nuevos usuarios en la base de datos de usuario LightSwitch automáticamente cuando se crea un nuevo perfil de usuario La limpieza y la configuración del usuario invitado Dado que este método es una solución totalmente diferente a exactamente el mismo problema,Le recomiendo que se restaura la copia de seguridad del proyecto realizado en el extremo de la parte 1 por lo que tiene una pizarra limpia antes de continuar. También es necesario seguir los siguientes pasos: Utilice el cliente de escritorio para borrar cualquier usuario de prueba que ha creado. Vuelva a agregar el permiso CanAddUsers en la ficha Control de acceso propiedades del proyecto de LightSwitch, ya que se han eliminado al restaurar la copia de seguridad. Eliminar la tabla UserProfiles. Vamos a hacer una nueva continuación. Volver a publicar el proyecto. Utilice el cliente de escritorio para eliminar el permiso (ahora en blanco) del papel UserRegistrant y volver a agregar el nuevo permiso CanAddUsers a ella. Utilizar su interfaz de servidor SQL para eliminar la tabla UserProfiles. Si desea poner en orden el servidor, iniciar sesión a través de FTP y borrar el archivo UserRegistrationService.svc que queda de la vieja Servicio WCF RIA. Deje el administrador y cuentas __userRegistrant y el papel UserRegistrant intacto como vamos a utilizar la misma solución para permitir que los nuevos usuarios crear cuentas a través de la cuenta de invitado como en la parte 2. Sisaltado la parte 2, siga las instrucciones en el Configurar un usuario invitado que puede agregar cuentas de usuario nueva sección hasta la parte donde se introduce el código fuente (que será diferente para esta solución). En esta solución, vamos a configurar la creación de usuarios a trabajar de esta manera: Crear una tabla UserProfiles que almacena todos los datos del perfil del usuario Al crear un usuario, escribiremos a UserProfiles directamente (en lugar de llamar al servicio WCF RIA) cuando se añade una nueva fila a UserProfiles, crear automáticamente un nuevo usuario en SecurityData.UserRegistrations crear datos de la tabla, haga clic derecho en la carpeta del servidor y elija Agregar tabla. Crear una tabla denominada UserProfiles con los campos de nombre de usuario, NombreCompleto, contraseña y correo electrónico como se muestra en la figura 10: Figura 10. La tabla UserProfiles Inserción de nuevos usuarios con el servicio WCF RIA, queremos asegurarnos de que sólo __userRegistrant puede añadir usuarios a la mesa, así que seleccione Código de escritura de la barra de herramientas y elegir el método UserProfiles_CanInsert. Escriba el siguiente código decumplir el permiso CanAddUsers sobre la mesa: UserProfiles_CanInsert vacío parcial (ref resultado bool) { // Sólo permiten a las personas con el permiso CanAddUsers para añadir nuevos usuarios Resultado = Application.Current.User.HasPermission (Permissions.CanAddUsers); } Ahora escribimos el código para hacer que un nuevo usuario sea en SecurityData.UserRegistrations genera automáticamente cuando se inserta una fila en UserProfiles. Elija Escribe Código y seleccione el método UserProfiles_Inserting. Este método se ejecutará después de UserProfiles_CanInsert pero antes de la fila se inserta en realidad. Aquí está el código: UserProfiles_Inserting vacío parcial (entidad UserProfile) { // Añadir nuevo usuario a la base de datos SecurityData var = NewUser this.DataWorkspace.SecurityData.UserRegistrations.AddNew (); NewUser.UserName = entity.UserName; NewUser.FullName = entity.FullName; NewUser.Password = entity.Password; // Guardar cambios this.DataWorkspace.SecurityData.SaveChanges (); } Cuando este código se ejecuta, un nuevoel usuario se añadirá a SecurityData.Registrations utilizando el mismo nombre de usuario, nombre completo y la contraseña cuando se intenta insertar una fila en UserProfiles. Necesitamos privilegios de administrador para hacer esto, por lo que necesitamos para elevar los permisos de __userRegistrant temporalmente mientras SecurityData.UserRegistrations se actualiza. Elija Escribe Código y seleccione el método SaveChanges_Executing, y añadir el código de elevación de privilegios: SaveChanges_Executing vacío parcial () { // Temporalmente elevar los permisos de usuario para que un nuevo usuario se puede añadir // La escalada de privilegios se retira una vez que el nuevo usuario se ha añadido // (Cuando los extremos de tuberías guardar) Application.Current.User.AddPermissions (Permissions.SecurityAdministration); } La limitación que puede leer los perfiles de usuario en el servicio de WCF RIA, modificamos la consulta por defecto sólo para volver el perfil para el usuario actualmente conectado. Esta vez, podemos utilizar el método UserProfiles_Filter para filtrar los resultados de la consulta no deseados de una manera similar.Elija Escribe Código y seleccione el método UserProfiles_Filter, y agregue el código siguiente: UserProfiles_Filter vacío parcial (ref Expresión <Func <UserProfile, bool >> filtro) { // Sólo permite al usuario ver su propio perfil filter = e = e.UserName> == Application.Current.User.Name; } Lo que sucede aquí es que cada fila de los resultados de la consulta se repiten a lo largo. La fila se coloca en E y luego se aplica un filtro a e después de la => operador. Si el filtro devuelve verdadero, la fila se retiene en los resultados de la consulta, de lo contrario se descarta. Aquí comparamos nombre de usuario de la fila a la del usuario que ha entrado, y sólo devuelven verdadero si coinciden. El efecto neto es que todas las filas se descartan excepto la fila (perfil) del usuario actual. En este punto, hemos replicado toda la funcionalidad del Servicio WCF RIA, pero sin ningún tipo de proyectos adicionales, tablas de códigos o de proxy / classes. Si se vuelve a publicar el proyecto puede probarlo en el ApplicationData.svc / UserProfiles punto final. Asignación de nuevos usuariosa un papel Utilice el cliente de escritorio para agregar una nueva función llamada del jugador. Esta será la función predeterminada que los nuevos usuarios se asignan a. En su código UserProfiles_Inserting, añadir las siguientes líneas justo antes de SaveChanges () se llama: // Asignar usuario a la función del jugador de forma predeterminada var = NewRoleAssignment NewUser.RoleAssignments.AddNew (); NewRoleAssignment.Role = this.DataWorkspace.SecurityData.Roles_Single ( "Jugador"); Esto asigna el nuevo usuario a la función del jugador antes de que los cambios se escriben en SecurityData. No se olvide de volver a publicar el proyecto para que los cambios surtan efecto. Almacenamiento de contraseñas Hay un problema con esta solución, que es que los datos NombreCompleto y la contraseña se almacena sin cifrar en la tabla UserProfiles así como en SecurityData.UserRegistrations. Realmente no queremos que esto ya que es un riesgo para la seguridad. Afortunadamente una adición de una línea para UserProfiles_Inserting será un tanto mitigar el problema. En primer lugar, editar la tabla UserProfiles modo que la contraseña ya no es necesaria unacampo (desactive la casilla requeridos para ello en el diseñador de tablas), el añadir el siguiente código a UserProfiles_Inserting después SecurityData.SaveChanges (): // No guardar la contraseña en UserProfiles entity.Password = ""; La contraseña se guarda en SecurityData.UserRegistrations cuando SecurityData.SaveChanges () se llama, pero después de que cambia el campo de la contraseña en una cadena vacía, de tal manera que cuando se escribe en UserProfiles cuando UserProfiles_Inserting extremos, sólo se almacenará un campo en blanco , y sin contraseña. El código fuente completo es el siguiente: using System; utilizando System.Collections.Generic; utilizando System.Linq; utilizando System.Text; utilizando Microsoft.LightSwitch; utilizando Microsoft.LightSwitch.Security.Server; utilizando System.Linq.Expressions; LightSwitchApplication espacio de nombres { ApplicationDataService clase parcial pública { UserProfiles_Filter vacío parcial (ref Expresión <Func <UserProfile, bool >> filtro) { // Sólo permite al usuario versu propio perfil filter = e = e.UserName> == Application.Current.User.Name; } UserProfiles_Inserting vacío parcial (entidad UserProfile) { // Añadir nuevo usuario a la base de datos SecurityData var = NewUser this.DataWorkspace.SecurityData.UserRegistrations.AddNew (); NewUser.UserName = entity.UserName; NewUser.FullName = entity.FullName; NewUser.Password = entity.Password; // Asignar usuario a la función del jugador de forma predeterminada var = NewRoleAssignment NewUser.RoleAssignments.AddNew (); NewRoleAssignment.Role = this.DataWorkspace.SecurityData.Roles_Single ( "Jugador"); // Guardar cambios this.DataWorkspace.SecurityData.SaveChanges (); // No guardar la contraseña en UserProfiles entity.Password = ""; } UserProfiles_CanInsert vacío parcial (ref resultado bool) { // Permitir que sólo las personas con elCanAddUsers permiso para añadir nuevos usuarios Resultado = Application.Current.User.HasPermission (Permissions.CanAddUsers); } SaveChanges_Executing vacío parcial () { // Temporalmente elevar los permisos de usuario para que un nuevo usuario se puede añadir // La escalada de privilegios se retira una vez que el nuevo usuario se ha añadido // (Cuando los extremos de tuberías guardar) Application.Current.User.AddPermissions (Permissions.SecurityAdministration); } } } Resumen En este punto tenemos: una mesa UserProfiles codificada que genera automáticamente un usuario en SecurityData.Registrations cuando una nueva fila se añaden restringido el acceso de tal manera que sólo el usuario invitado puede agregar nuevas cuentas (filas) de inserción en UserProfiles acceso restringido de tal manera que los usuarios pueden Sólo tienen acceso a sus propios perfiles eliminan la necesidad de que el cliente para conocer la contraseña de administrador o tener privilegios de administrador resuelto el problema de la UserProfiles ser utilizado como puerta trasera paraobtener información sobre el perfil que tuvimos con el Servicio RIA WCF elimina una gran cantidad de código repetitivo y complejidad elimina la necesidad de actualizar el código cuando los campos de la tabla UserProfiles cambiar la mesa ahora se pueden editar en el diseñador de LightSwitch, a diferencia de la WCF RIA servicio de seguridad simplificada permisos que hace cumplir en comparación con el servicio WCF RIA donde tanto las tablas en el proyecto LightSwitch y el punto final de servicio WCF RIA debe estar asegurado Entonces, ¿qué es la desventaja? En pocas palabras, tenemos dos campos duplicados innecesarios - FullName y Contraseña - en UserProfiles. La razón de esto es que cuando se inserta una fila en UserProfiles, LightSwitch, por supuesto, espera un valor para cada campo, así que tener los campos duplicados es inevitable. Como hemos demostrado anteriormente, los campos pueden ser borradas con código si se desea, pero todavía es un desperdicio de espacio de almacenamiento en la base de datos. Conclusión Ahora hemos diseñado tres maneras diferentes de agregar usuarios: utilizar la cuenta de administrador directamente. 
