O comando certo no lugar certo

Essa semana aconteceu uma daquelas coisas muito irritantes. Ao liberar, em produção, uma nova versão do sistema a autenticação com o Facebook não estava funcionando. E não posso dizer que foi falta de teste, havia sido bem verificado.

Durante umas 3 horas eu mexi em todas as configurações possíveis e impossíveis, tanto no app do Facebook, quanto no IIS e nada. Com as configurações do ambiente de desenvolvimento funcionava perfeitamente.

Depois de algumas trocas de ideias eu fui olhar no código fonte em C#, revira daqui e dali e acho uma classe que não sabia que existia (feita por um outro colega) e começo a depura-lá.

O código da classe não parecia ter sido feito pelo meu colega, procurei na internet e achei um código bem parecido (http://social.msdn.microsoft.com/Forums/en-US/7ef9a2b0-c150-458e-9980-d1254837d0dd/aspnet-mvc-facebook-login-returns-wrong-url), porem com uma leve diferença no método GetHtml.

Para encurtar a história, quando a URL para o Facebook era montada (http://endeco.com.br:80/LoginFacebook) a porta 80 gerava um bug em algum lugar na API do próprio Facebook. Logo o comando

.Replace("%3a80", "")

retirava a anomalia e o código funcionou perfeito.

No ambiente de testes funcionava correto pois o endereço era http://localhost:52576, uma porta qualquer.

MALDIÇÃO!!!!!!!

Troca de Informações Confidenciais

Estava eu trabalhando em um projeto com WCF  (Windows Communication Foundation) onde queria retornar uma classe mais simples de dado, por exemplo sem tantas propriedades.

Qual foi a minha primeira ideia (e que executei), criar uma interface, por exemplo:

public interface IPessoa
{
string Nome { get; }
int Idade { get; }
}

E criei a classe:

public class Pessoa : IPessoa
{
public string Nome { get; set; }
internal DateTime DataNascimento { get; set; }
public int Idade { get; { return Convert.ToInt32((DateTime.Today -      DataNascimento).TotalDays / 365.0);}}
}

O legal é que tudo parece funcionar, o serviço compila e tudo mais. Pena que não é a maneira correta alem de não funcionar. O correto é criar apenas uma classe e colocar atributos sobre os elementos que devem ser serializados, assim:
[DataContract]
public class Pessoa : IPessoa
{
public Pessoa(string nome, DateTime dataNascimento)
{
Nome = nome;
DataNascimento = dataNascimento;
Idade = Convert.ToInt32((DateTime.Today - DataNascimento).TotalDays / 365.0);
}
[DataMember]
public string Nome { get; set; }
public DateTime DataNascimento { get; set; }
[DataMember]
public int Idade { get; set; }
}

Também é bem simples e nesse caso funciona.

Autenticação com o Twitter em várias etapas

OAuth

Comecei a estudar sobre a autenticação OAuth para utilizá-la com o Twitter. Protocolo utilizado em muitos serviços web e é a forma mais segura de permitir que uma terceira aplicação acesse um serviço  (o Twitter no caso) de maneira segura e prática.

Uma forma de utilizar o Twitter seria solicitando aos usuários que informassem seu usuário e senha para a aplicação intermediária (vou chamá-la de Hub). Um exemplo pode ser visto na  figura abaixo.

Twitter

Esse modelo apresenta diversos problemas ligados à segurança. Informando o usuário e senha para o Hub, esta aplicação pode realizar qualquer operação no Twitter em nome do usuário, inclusive realizar alterações no perfil.

Justamente para resolver esse problema, foi criado o OAuth que restringe o acesso a operações determinadas sem o fornecimento de senhas para o Hub. O processo pode ser visto na figura abaixo.

OAuth

A autenticação acontece da seguinte forma:

O Hub realiza uma solicitação ao Twitter pedindo um endereço, para que um usuário se vincule a ele. Quando o usuário final visualiza a página, é solicitada para confirmar ao Twitter se perfil de usuário e concordar ou não com a vinculação de seu perfil com o Hub. A página já estamos acostumados a ver.

Twiiter

Após essa confirmação, o Twitter chama o Hub, informando uma nova chave gerada sem vinculação com o usuário e senha reais. Isso garante que o Hub desconhece os dados do usuário.

Continuar lendo