Seguridad y confianza
.NET Framework tiene un modelo de seguridad que trata las aplicaciones de manera diferente dependiendo de su origen. Los ejecutables y ensamblados que proceden de la máquina de un usuario suelen ejecutarse con plena confianza; los mismos ejecutables y ensamblados se ejecutan a través de Internet por lo general con confianza parcial. Esto es para evitar que el código malintencionado lea o modifique la información a la que no debe tener acceso, como archivos locales, elementos en el Portapapeles y otros recursos. Si un ejecutable llama a un ensamblado, que a su vez llama a otro ensamblado que requiere un determinado nivel de confianza, se aplica el nivel de confianza más bajo de todos los componentes de la cadena. Sin embargo, un administrador de una máquina puede establecer permisos específicos que invaliden los permisos predeterminados.
En La práctica se proporciona información general sobre el modelo de seguridad en Controles seguros, Light-Weight Client-Side y puede obtener más profundidad sobre el modelo de seguridad en Seguridad de acceso al código en La práctica. Puede encontrar una buena introducción a la seguridad de las bibliotecas (que es especialmente importante para los objetos UserControl en una página web) en Uso de bibliotecas de código de confianza parcial y se puede encontrar otra información de seguridad sobre los controles administrados en Escritura de controles administrados seguros.
Permisos
La mayoría de los objetos administrados y miembros de tablet PC Technologies API tienen dos requisitos:
- La ejecución siempre es necesaria.
- FullTrust es necesario cuando se realiza la acción de seguridad InheritanceDemand . Esto significa que se requiere plena confianza cuando una clase derivada hereda una clase o invalida un método del SDK de Pc tablet.
En la tabla siguiente se enumeran las clases y los miembros que requieren permisos adicionales. Los permisos de una clase determinada también se aplican a todos sus miembros que no aparecen en esta tabla.
Nota
Por lo general, es preferible usar un control en lugar de un identificador (IntPtr) para constructores, ya que los controles requieren menos permisos. De forma similar, es preferible usar un objeto Graphics en lugar de un identificador para Renderer.Draw, Renderer.InkSpaceToPixel y Renderer.PixelToInkSpace.
Nota
Las propiedades InkCollector.Handle y InkOverlay.Handle no requieren el permiso SecurityPermissionFlag.UnmanagedCode si el identificador es para un control Windows Forms, pero sí para otras ventanas.
Nota
Para la clase PenInputPanel , los métodos y propiedades siguientes requieren SecurityPermissionFlag.AllFlags: PenInputPanel(IntPtr), AttachedEditWindow, Busy, CommitPendingInput, CurrentPanel, DefaultPanel, EnableTsf, Factoid, Height, HorizontalOffset, InputFailed, Left, MoveTo, PanelChanged, PanelMoving, Refresh , Top, VerticalOffset, Visible, VisibleChanged y Width.
Otras consideraciones
Algunas otras consideraciones de seguridad conocidas son:
- Microsoft Internet Explorer 6 o superior es necesario para que los controles web funcionen correctamente. Con Internet Explorer 5.5, solo se cargan los controles administrados iniciales; No se pueden cargar controles adicionales dinámicamente en tiempo de ejecución.
- Si usa Windows XP Service Pack 2 (SP2) y CLR1.0, tener controles web en Internet Explorer requiere agregar el sitio como sitio de confianza, incluso si están en la zona intranet. Sin embargo, al hacerlo, ya no se ejecutarán en la zona Sitio de confianza, aunque se ejecutan en la zona intranet. Este problema se ha corregido con CLR1.1.