• No results found

Political Relationship

4. COLOMBIAN DATA PROTECTION REGULATION (Law 1581 2012)

5.4 Political Relationship

Para que uma aplicação seja integrada com a conta de armazenamento devem ser providenciados quer o nome da conta, quer as chaves de acesso que podem ser obtidas no portal de administração. Esta informação deve ser guardada num ficheiro de configuração para que possa ser alterada com facilidade no futuro. Assim, a informação de acesso à

Início WebControls.FileUpload Administrador Selecciona Imagem Administrador Submete Form Ficheiro Seleccionado? não Lê o nome do ficheiro sim

Lê o caminho do directório local do ficheiro de configuração

Junta o caminho com o nome

Envia e Guarda a imagem no Servidor Administração de Produtos Envio com sucesso? Fim Apresenta erro sim não A A

65 conta de armazenamento pode ser acedida na aplicação CloudShop através da propriedade MyDATAConnString da classe de acesso ao ficheiro de configuração.

O envio das imagens passou a ser efetuado segundo o fluxograma apresentado na Ilustração 17.

Ilustração 17 - Fluxograma do envio de imagens depois da migração

Quando o formulário é submetido é criado um cliente do serviço de BLOBs do Windows Azure recorrendo à informação de acesso armazenada no ficheiro de configuração e à API .NET. Através do cliente é verificado se o container (abstração que permite agrupar os

Início WebControls.FileUpload Administrador Selecciona Imagem Administrador Submete Form Ficheiro Seleccionado? não sim Lê a informação de acesso à conta de armazenameto a partir

do ficheiro de configuração Envia e Guarda a imagem na nuvem Administração de Produtos Envio com sucesso? Fim Apresenta erro sim não API .NET Cria um cliente para o serviço de BLOBs O container existe? não Cria container e atribui permissões de acesso A imagem é full- size? sim Lê o directório virtual para imagens full-size do

ficheiro de configuração

Lê o directório virtual para thumbnails do ficheiro de configuração

sim não

Junta o directório virtual com o nome e guarda uma referência para o BLOB

A

66 BLOBs) existe, se não existir é criado e são-lhe atribuídas permissões de acesso. Por omissão, um container é privado o que não se adequa ao propósito que queremos. As permissões de acesso público ao container devem ser alteradas sendo que os valores possíveis estão presentes na enumeração BlobContainerPublicAccessType [111]:

Blob – Com este tipo de permissão é possível a um utilizador anónimo ler o conteúdo e os metadados associados a qualquer BLOB dentro de um determinado container. É contudo negada a leitura dos metadados associados ao container bem como a listagem dos seus conteúdos.

Container – Todas as permissões do anterior sem as restrições de listagem e da leitura dos metadados ao nível do container.

Off – Não são permitidos acessos anónimos.

O valor escolhido para o armazenamento de imagens do sítio foi container. Dentro de um container não é possível criar diretórios no entanto, é possível criar uma estrutura hierárquica ao acrescentar um caminho virtual ao nome do ficheiro [112]. Por exemplo, na aplicação CloudShop é acrescentado o caminho dado pela propriedade FSImagesVirtualFolder ao nome da imagem, se a imagem se chamar “image001.png” o nome do BLOB a gravar no container será “FSimages/image001.png”, na base de dados é somente guardado o nome original “image001.png”. Esta técnica permite filtrar as imagens dentro do container em imagens full-size (guardadas no diretório virtual FSimages) e thumbnails (guardadas no diretório virtual TNimages). O facto de se guardar o nome original na base de dados permite que a alteração da conta de armazenamento fique circunscrita ao ficheiro de configuração e à alteração da informação de acesso. Para completar o processo a imagem é enviada para a nuvem passando a estar disponível em todas as instâncias da aplicação e a beneficiar da escalabilidade, alta disponibilidade e tolerância a falhas que caracterizam o serviço.

Para se evitar realizar operações na API sem ser necessário instanciar um cliente da conta de armazenamento sempre que é apresentada uma imagem, foram criados dois métodos na classe LinkFactory: ToProductImageFS e ToProductImageTN. Estes métodos permitem construir o URL completo para o BLOB usando para o efeito a propriedade BLOBImageDirectory que armazena o caminho para o serviço de armazenamento de BLOBs segundo a convenção apresentada na Listagem 5.

67

5.3.3.6. Transferência de Informação entre Páginas

O protocolo HTTP é um protocolo stateless, pelo que, por omissão, todos os pedidos feitos ao servidor Web são independentes e não guardam estado acerca dos pedidos anteriores. Para tornar a informação persistente entre pedidos deve ser empregue um dos métodos da Tabela 10. Método Compatível com o Windows Azure Comentários

Cookies Sim Como os cookies são guardados no cliente e

requisitados pelo servidor mesmo que a instância mude, o valor continua a conseguir ser lido.

Variáveis de Sessão Não As variáveis de sessão encontram-se guardadas na memória do servidor: se num pedido for chamado um servidor diferente daquele onde foi guardado o valor, o valor encontra-se indisponível.

Query String Sim Os valores são enviados junto com o URL da página sob a forma variável=valor.

Cross-Page Posting Sim Este método usa a propriedade PostBackUrl do botão de submeter o formulário. Os valores do formulário são enviados por POST para a página de destino.

Server.Transfer Sim Se for utilizado o evento Click do botão de submeter e o pedido for redireccionado para outra página é

importante ter em conta que deve ser usado o método Server.Transfer em vez do Response.Redirect que não preserva o formulário. Para preservar o formulário, o segundo parâmetro do Server.Transfer deve ser true.

Tabela 10 - Métodos para fazer persistir informação entre páginas ASP.NET

Durante os testes efetuados verificou-se que as variáveis de sessão não funcionavam no Windows Azure quando era usada mais do que uma instância. De facto, quando um utilizador acede ao sítio através de um navegador é-lhe atribuído um ID de sessão que é enviado em pedidos posteriores através de um cookie. O ID de sessão serve para fazer o mapeamento entre o utilizador e as variáveis guardadas no servidor a que damos o nome de variáveis de sessão. Por omissão (Listagem 6) as variáveis de sessão são guardadas na memória do processo responsável por hospedar a aplicação ASP.NET [83] ou seja, as variáveis só estão acessíveis na instância em que foram definidas.

<sessionState mode="InProc"> </sessionState>

RELATERTE DOKUMENTER