ID do artigo: 311301 - Última revisão: quinta-feira, 19 de abril de 2007 - Revisão: 5.3 Como o Internet Explorer determina as permissões para módulos (assemblies) do .NET Framework
SumárioAplicativos baseados na Web podem usar o Microsoft Internet Explorer 5.5 e posterior para baixar e executar módulos (assemblies) Microsoft .NET Framework. Este artigo descreve como o Internet Explorer determina as permissões que são concedidas para módulos (assemblies). Mais InformaçõesAssemblies do .NET framework que são implantados de uma intranet geralmente recebem o padrão definir permissões de intranet. Este conjunto permite que o código executar somente um conjunto muito limitado de funções. Essas funções incluem o seguinte:
.NET framework Service Pack 1 (ou V1 para essas versões localizadas receber essa alteração) irá definir uma nova diretiva de segurança padrão, no qual gerenciado código não pode ser download a partir da Internet zona em questão. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: 317399
(http://support.microsoft.com/kb/317399/
)
.NET Framework no padrão alterar diretiva de segurança em nível de máquina O CLR (Common Language Runtime) foi projetado para dar suporte a uma variedade de diferentes aplicativos .NET Framework. Atualmente, cada tipo de aplicativo requer um trecho de código para iniciar. Esse código é conhecido como um host CLR. A responsabilidade de um host é carregar a versão correta do CLR em um processo, definir os domínios de aplicativo dentro do processo e executar código do usuário dentro desses domínios.Para fornecer um ambiente isolado para cada tipo de aplicativo, o CLR oferece suporte a vários hosts de runtime diferentes, bem como Internet Explorer. Todos os hosts CLR devem começar com um fragmento de código não gerenciado. Para essa finalidade, o .NET Framework fornece um conjunto de interfaces de programação de aplicativo não gerenciado (APIs). Os hosts do aplicativo podem usar essas APIs não gerenciadas para obter o CLR em execução. O .NET Framework inclui dois componentes que lidam com os componentes do .NET Framework no Internet Explorer. O primeiro componente, Mscorie.dll, contém um filtro de tipo MIME (Multipurpose Internet Mail Extensions). Este filtro conecta no Internet Explorer e monitora todos os fluxos de dados entrada com o MIME tipo application/octet-stream. Uma função principal dessa correção de inicialização é examinar o fluxo de entrada para ver ou não o fluxo é um código gerenciado. Se o filtro determina que os dados de entrada não são um código gerenciado, o filtro permitirá que para manipular os dados da forma que ele foi anteriormente. Se o filtro de tipo MIME determina que o fluxo é um módulo do .NET Framework, o filtro carrega o segundo componente. O segundo componente é um assembly gerenciado chamado IEHost. O IEHost chamará a API CorBindToRuntimeByCfg para carregar o CLR em um processo. O IEHost também chama IEManager, um Gerenciador de segurança que cria um domínio de aplicativo dentro do processo. Depois que o host cria e configura o domínio do aplicativo, o host chama em seu objeto de fábrica para criar uma instância do objeto de Framework .NET solicitado e para carregar e executar código de usuário nesse domínio de aplicativo. Host do Internet Explorer define um aplicativo por site por padrão. O diretório raiz do site é considerado o diretório raiz do aplicativo. O host tem um alto grau de controle sobre as permissões que recebe o código quando ele é executado em um domínio de aplicativo especificado. Todo o código que é executado no Common Language Runtime deve ser parte de um assembly. Todos os aplicativos que tem como alvo o CLR devem interagir com o sistema de segurança do tempo de execução. Quando um aplicativo é executado, o runtime automaticamente avalia o aplicativo. O tempo de execução também oferece o aplicativo um conjunto de permissões. Essas permissões sejam baseiam na evidência que o aplicativo fornece e na diretiva de segurança. Formas comuns de evidências para IEHost incluem StrongName, URL, sites, zona e Publisher. O CLR permite o código para executar essas operações que o código tem permissão para executar. O .NET Framework contém um objeto de permissão para cada recurso está disponível no computador do usuário. Esses recursos incluem E/s de arquivos, acesso Web, execução de código não gerenciado e muito mais. O tempo de execução usa esses objetos de permissão para impor restrições no código gerenciado. Para conceder permissões para o código do .NET Framework, os administradores ou usuários avançados grupo as permissões em um conjunto de permissões. A permissão definida e é aplicada a um grupo de códigos. Um assembly específico (a unidade básica de código para conceder permissões de segurança) é um membro de um grupo de código se ele satisfaz a condição de associação do grupo de código. Para exibir as permissões padrão que são fornecidas para assemblies .NET, use a ferramenta de configuração do .NET Framework (Mscorcfg.msc). Você também pode usar essa ferramenta para exibir e configurar a diretiva de segurança. Os administradores podem definir conjuntos de permissão personalizada-nomeadas, desde que seus nomes são diferentes dos conjuntos de permissão nomeado interna de. Referências Adendo do Microsoft .NET Framework 1.0 http://msdn2.microsoft.com/en-us/library/ms973854.aspx (http://msdn2.microsoft.com/en-us/library/ms973854.aspx) segurança do Internet Explorer e execução gerenciada http://msdn2.microsoft.com/en-us/library/101853ac(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/101853ac(vs.71).aspx) hosts do domínio de aplicativo http://msdn2.microsoft.com/en-us/library/6700e49f(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/6700e49f(vs.71).aspx) padrão de diretiva de segurança http://msdn2.microsoft.com/en-us/library/03kwzyfc(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/03kwzyfc(vs.71).aspx) grupos de códigos http://msdn2.microsoft.com/en-us/library/ka9xc0ek(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/ka9xc0ek(vs.71).aspx) evidência http://msdn2.microsoft.com/en-us/library/7y5x1hcd(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/7y5x1hcd(vs.71).aspx) Criando suas próprias permissões de acesso código http://msdn2.microsoft.com/en-us/library/yctbsyf4(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/yctbsyf4(vs.71).aspx) Microsoft.NET: implementar um host personalizado do Common Language Runtime para seu aplicativo gerenciado http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/03/clr/TOC.asp (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/03/clr/TOC.asp) hospedar controles de cliente seguros, leves no Microsoft Internet Explorer http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx (http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx) A informação contida neste artigo aplica-se a:
Tradução automáticaIMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado. Clique aqui para ver a versão em Inglês deste artigo: 311301
(http://support.microsoft.com/kb/311301/en-us/
)
| Outros Recursos Outros Sites de Suporte
ComunidadesObtenha Ajuda AgoraTraduções deste artigo
|






Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email



Voltar para o início