Segurança e confiança
O .NET Framework tem um modelo de segurança que trata os aplicativos de forma diferente dependendo de sua origem. Executáveis e assemblies que são do computador de um usuário geralmente são executados com confiança total; os mesmos executáveis e assemblies executados pela Internet geralmente são executados com confiança parcial. Isso é para impedir que o código mal-intencionado leia ou modifique informações às quais ele não deve ter acesso, como arquivos locais, itens na Área de Transferência e outros recursos. Se um executável chamar um assembly, que por sua vez chama outro assembly que requer um determinado nível de confiança, o nível mais baixo de confiança de todos os componentes na cadeia será aplicado. No entanto, um administrador em um computador pode definir permissões específicas que substituem as permissões padrão.
Uma visão geral do modelo de segurança é fornecida em Segurança, controles de Light-Weight Client-Side e você pode obter mais profundidade sobre o modelo de segurança na Segurança de Acesso ao Código na Prática. Uma boa visão geral sobre a segurança de bibliotecas (que é especialmente importante para objetos UserControl em uma página da Web) pode ser encontrada em Usando bibliotecas de código parcialmente confiável, e outras informações de segurança sobre controles gerenciados podem ser encontradas em Gravando controles gerenciados seguros.
Permissões
A maioria dos objetos e membros gerenciados na API do Tablet PC Technologies tem dois requisitos:
- A execução é sempre necessária.
- FullTrust é necessário quando a ação de segurança InheritanceDemand ocorre. Isso significa que a confiança total é necessária quando uma classe derivada herda uma classe ou substitui um método do SDK do Tablet PC.
A tabela a seguir lista as classes e os membros que exigem permissões adicionais. As permissões para uma determinada classe também se aplicam a todos os seus membros não listados nesta tabela.
Observação
Geralmente, é preferível usar um controle em vez de um identificador (IntPtr) para construtores, pois os controles exigem menos permissões. Da mesma forma, é preferível usar um objeto Graphics em vez de um identificador para Renderer.Draw, Renderer.InkSpaceToPixel e Renderer.PixelToInkSpace.
Observação
As propriedades InkCollector.Handle e InkOverlay.Handle não exigem permissão SecurityPermissionFlag.UnmanagedCode se o identificador for para um controle Windows Forms, mas sim para outras janelas.
Observação
Para a classe PenInputPanel , os seguintes métodos e propriedades exigem SecurityPermissionFlag.AllFlags: PenInputPanel(IntPtr), AttachedEditWindow, Busy, CommitPendingInput, CurrentPanel, DefaultPanel, EnableTsf, Factoid, Height, HorizontalOffset, InputFailed, Left, MoveTo, PanelChanged, PanelMoving, Refresh , Top, VerticalOffset, Visible, VisibleChanged e Width.
Outras considerações
Algumas outras considerações de segurança conhecidas são:
- O Microsoft Internet Explorer 6 ou superior é necessário para que os controles da Web funcionem corretamente. Com a Internet Explorer 5.5, somente os controles gerenciados iniciais são carregados; você não pode carregar controles adicionais dinamicamente em tempo de execução.
- Se você estiver usando o Windows XP Service Pack 2 (SP2) e o CLR1.0, ter controles da Web na Internet Explorer exigir a adição do site como um site confiável, mesmo que eles estejam na zona intranet. No entanto, quando você fizer isso, eles não serão mais executados na zona site confiável, embora sejam executados na zona intranet. Esse problema foi corrigido com CLR1.1.