Usuarios
Se debe definir cada usuario de ThingWorx.
Los nombres de usuario pueden ser direcciones de correo electrónico. En los nombres de usuario no se pueden incluir los siguientes caracteres:
• & (signo et)
• : (dos puntos)
 |
En ThingWorx 8.4.7 y versiones posteriores, se aceptan los caracteres de dos puntos en los nombres de usuario, aunque no se podrá iniciar sesión a través del autenticador básico y Active Directory no soporta el carácter de dos puntos en los nombres de usuario. Se soportan otras formas de autenticación, tales como el inicio de sesión de formulario y los autenticadores personalizados.
|
• / (barra inclinada)
• + (signo más)
Un usuario puede pertenecer a cualquier número de grupos y se le pueden asignar muchas combinaciones de derechos y permisos. A diferencia de las cosas, los usuarios no tienen servicios, eventos ni suscripciones.
Es posible acceder a las propiedades del usuario actual (el usuario con la sesión iniciada) de Mashup Builder en la ficha Usuario. También están disponibles en un mashup en tiempo de ejecución. Es posible crear y clonar usuarios en tiempo de ejecución empleando la biblioteca de servicios de recursos.
Usuarios por defecto
|
Usuario por defecto
|
Detalles
|
|---|---|
|
Administrador
|
La cuenta Administrador es una cuenta de usuario por defecto, que no se puede borrar. La cuenta Administrador tiene permisos de creación, lectura, actualización y eliminación para todas las entidades y todos los permisos de ejecución en tiempo de ejecución.
|
|
Superusuario
|
Si se utiliza Extension SDK para el desarrollo de extensiones y se necesita acceder a un recurso protegido al que puede que el usuario que está realizando la solicitud no tenga acceso, se pueden generar contextos de superusuario o usuario del sistema mediante los métodos de fábrica adecuados. Es necesario asegurarse de que el contexto de seguridad se utilice solamente para acceder a los recursos protegidos que son necesarios para la funcionalidad adecuada.
|
|
Usuario del sistema
|
Para obtener más información, consulte
Usuario del sistema.
|
Directrices para asignar nombres a los usuarios
PTC recomienda encarecidamente lo siguiente:
• No incluir información confidencial en los nombres de usuario.
• Para casos de uso altamente confidenciales, considere la posibilidad de emplear nombres de usuario aleatorios o asignados de forma arbitraria en lugar de derivarlos de datos públicos definidos por el usuario, según las
recomendaciones de OWASP.
Configuración de permisos para usuarios que no son administradores y depuración de mensajes de error
Los usuarios que no son administradores no tienen ningún permiso de fábrica. No pueden ver nada hasta que un Administrator lo permita explícitamente. Siga estas sugerencias para configurar nuevos usuarios y depurar mensajes de error cuando se restrinjan determinadas acciones:
• En ThingWorx 8.4.0 y versiones posteriores, los usuarios nuevos se deben colocar en el ComposerUser
grupo de usuarios en ThingWorx. De este modo, el usuario podrá iniciar sesión en Composer con permisos de invocación de servicio en tiempo de ejecución.
• Si hay otras acciones que deberían estar disponibles para un usuario, pero aparecen restringidas, un usuario Administrador puede depurar el error mediante el
Registro de aplicación. Verifique si hay mensajes de nivel de error que indiquen que es posible que falte una entidad o que no se puede autorizar alguna función. A continuación, se muestran ejemplos de mensajes de error:
◦ Entity Not Found : [CurrentSessionInfo]] indica que un Administrador debe conceder al usuario no administrativo permisos de visibilidad para ver el recurso CurrentSessionInfo.
◦ Not authorized for ServiceInvoke on GetDaysRemainingInLicense in LicensingSubsystem] indica que un falta un permiso de invocación de servicio en tiempo de ejecución para el servicio GetDaysRemainingInLicense en el subsistema de licencias para ese usuario que no es administrador.
• Las entidades de usuario que se migran desde una versión preexistente de ThingWorx (anterior a la versión 8.4.0) se deben añadir manualmente al grupo de usuarios ComposerUsers. ThingWorx no migrará las entidades de usuario importadas al grupo de usuarios ComposerUsers automáticamente.
Extensiones de usuario
Un usuario puede tener cualquier número de propiedades, denominadas extensiones de usuario. Las propiedades de extensión de usuario se almacenan en tablas de configuración (son valores STRING con asignación rigurosa). Por ello, no es posible añadir una propiedad de infotable a la definición de datos de las extensiones de usuario y, a continuación, definir un valor en esa infotable para el usuario. El uso más común de las tablas de configuración es almacenar las credenciales y la información de host para un recurso externo. Las
tablas de configuración no se deben utilizar para almacenar datos dinámicos que se actualizan con frecuencia.
|
|
Dado que la tabla de configuración de extensiones de usuario es un tipo único de tabla de configuración que no utiliza una estructura de definición de datos simple, hay servicios que no se pueden utilizar para modificarla. Estos servicios son SetConfigurationTable, SetConfigurationTableRows y SetMultiRowConfigurationTable.
|
Para modificar una configuración de extensiones de usuario, se debe editar su definición de cosa en > > .
Si se permite la redefinición de contraseña a los usuarios, las siguientes propiedades de extensión de usuario son obligatorias:
• firstName
• lastName
• emailAddress
Permisos de usuario en los servicios
Los servicios están diseñados explícitamente para no requerir permisos al usuario que inicia el servicio. Por ejemplo, los usuarios pueden cambiar sus propias contraseñas. No se puede impedir que un usuario utilice un servicio en su propia cuenta.
Preferencia de idioma
En el campo Idiomas, un administrador que sepa los nombres de idiomas disponibles puede introducir una lista separada por comas y ordenada (por ejemplo, ca,es,hu,fr-CA) o seleccionar de una lista de idiomas disponibles. El primer idioma de la lista es el idioma preferido del usuario. Si un usuario no tiene las preferencias de idiomas definidas, se utilizan las
tablas de localización Por defecto y Sistema.
El valor mostrado (traducción) de un token de localización lo determinan las preferencias de idioma del usuario, las tablas de localización configuradas en el sistema y la traducción del token existente en las tablas de localización especificadas.
Por ejemplo, la preferencia de idioma de un usuario es fr,pt,ru,hi (francés, portugués, ruso, hindi). El sistema se configura con tablas de localización para es (español), fr-CA (francés canadiense), it (italiano),pt-BR (portugués brasileño), ru (ruso) y el valor por defecto (probablemente inglés). El sistema busca un valor para un token determinado. El sistema primero busca una tabla de localización fr, que existe. Sin embargo, el token no se incluye en la tabla de localización fr. Por consiguiente, el sistema sigue a la tabla de localización pt. No hay ninguna tabla de localización pt en el sistema. Por consiguiente, pasa a ru. El sistema encuentra la tabla de localización ru y el token. El token tiene un valor, de modo que se muestra ese valor en la interfaz de usuario.