Arquitetura de Serviço Web

[Neves]

Olá,

Tenho uma idéia para criar um serviço de banco de dados sobre HTTP.
A idéia é criar um serviço simples para qualquer um utilizar direto no
site utilizando javascript ou flash.

Seria um serviço REST assim:
wdb.com/<database>/<table>

Mas o problema esta em encontrar uma maneira segura de fazer isso.
Por exemplo, eu quero que o cliente do site meusite.com, consiga fazer
um cadastro apenas enviando um post com os campos para: wdb.com/
meusite/cadastros
Mas eu não quero que qualquer pessoa possa fazer um post para o mesmo
endereço e gerar um novo cadastro.
Uma solução que quero evitar seria utilizar uma linguagem server como
proxy:
meusite(client side) =POST> meusite(server side adiciona a chave do
cliente) =POST> wdbcom

Mas quero que a solução não precisa utilizar server side, pelo menos
não como proxy apenas para adicionar a chave única.

Uma ideia que tive é a seguinte:
Cliente acessa site meusite.com
meusite.com pelo server side, cria uma chave unica para este visitante
e envia esta chave para wdb.com
meusite.com pelo client side, utiliza estão esta chave dentro do
formulário, para submeter o post direto para wdb.com
wdb.com recebe o post e só aceita se a chave for válida.

Esta solução teria a mesma falha de qualquer cookie, ou seja, se
copiar de um para outro, funcionaria.

Claro que adicionado a tudo isso, ainda teria verificação da versão do
navegador se é a mesma, verificação do Refer, IP, etc, mas são medidas
apenas para dificultar, nenhuma irá resolver o problema.
A chave também será gerada liberando a utilização por n vezes, para
determinados bancos/tabelas/metodos PUT, POST, DELETE e ainda com data
de expiração.

Alguma sugestão?

[G. Sobrinho]

Essa é a idéia do CouchDB não? http://couchdb.apache.org/

2009/10/29 Neves <marcos...@gmail.com>

--
Cordialmente,

Gabriel Sobrinho
Diretor de desenvolvimento

Hite - Comunicação Digital e Mídia Interativa
http://www.hite.com.br/

+55 31 8775 8378

[Neves]

Talvez no futuro, mas não ainda.
A questão aberta é sobre como autenticar um cliente da forma mais
simples possível.
Acho que a única solução será permitir GET e POST publicamente e PUT/
DELETE apenas para usuário autenticado.
E todo POST feito sem autenticação, precisaria ser aprovado pelo do
autenticado.

A intenção é criar um banco online onde seja simples criar mural de
mensagem, enquetes, notícias, etc, com pouco conhecimento de
programação.
Por isso estou tentando evitar ao máximo a utilização de server-side.

On 29 out, 19:08, "G. Sobrinho" <gabriel.sobri...@gmail.com> wrote:
> Essa é a idéia do CouchDB não?http://couchdb.apache.org/
>

> 2009/10/29 Neves <marcos.ne...@gmail.com>

>
>
>
>
>
>
>
> > Olá,
>
> > Tenho uma idéia para criar um serviço de banco de dados sobre HTTP.
> > A idéia é criar um serviço simples para qualquer um utilizar direto no
> > site utilizando javascript ou flash.
>
> > Seria um serviço REST assim:
> > wdb.com/<database>/<table>
>
> > Mas o problema esta em encontrar uma maneira segura de fazer isso.
> > Por exemplo, eu quero que o cliente do site meusite.com, consiga fazer
> > um cadastro apenas enviando um post com os campos para: wdb.com/

> > meusite/cadastros <http://wdb.com/%0Ameusite/cadastros>

> Hite - Comunicação Digital e Mídia Interativahttp://www.hite.com.br/
>
> +55 31 8775 8378

[maxguzenski]

Mas token não resolveria esse problema? assim como o flickr faz e
muito outros sites?

O cara se cadastra no teu site e ganha um token (algo como: XDBFBS8SW-
SNDND32-SDJOOKI2) e sempre que ele chamar a tua URL ele tem q passar
esse token. E com ele tu já sabe quem é e o que pode fazer.

[Neves]

Pois é, mas se o token ficar exposto no formulário, outra pessoa pode
copiar e utilizar o mesmo token.
Isso funcionaria se o token for utilizado apenas no server-side.

[Joao Jose Pedrini]

Olá,

Isso é um problema bem sério e complexo e, como todo problema de segurança, não tem solução sem falhas. Trabalhei numa Startup que teria um serviço com o mesmo problema e, até o momento que sai, não encontramos a solução.

Vou dar algumas dicas que podem clarear as suas idéias, me lembro que me foram muito úteis mas como eu disse, eu mesmo não consegui resolver por completo.

Primeira coisa, use o http://ajaxpatterns.org/, lá tem bastante conteúdo e pode ser muito útil. Busque por Security e Authorization em AJAX (http://ajaxpatterns.org/Security_Links). Me lembro (visualmente) que este link (http://dev.mixendo.com/wiki/Mixendo_XHR_Security) é interessante.  Leia sobre o OAuth, acho que esse é o caminho. 

Como não consegui pensar na solução do problema, peço que, se você conseguir, comunique para a comunidade, tenho bastante interesse na solução. Também estarei a disposição, levei tanta porrada desse assunto que tenho uma certa experiência

Abraços.

--
Joao Jose Pedrini
joaojos...@gmail.com

[Neves]

Muito obrigado. Sua ajuda será de grande valia.
Vou dar uma estudada nos links.

On 30 out, 17:59, Joao Jose Pedrini <joaoj...@usosim.com.br> wrote:
> Olá,
>
> Isso é um problema bem sério e complexo e, como todo problema de segurança,
> não tem solução sem falhas. Trabalhei numa Startup que teria um serviço com
> o mesmo problema e, até o momento que sai, não encontramos a solução.
>
> Vou dar algumas dicas que podem clarear as suas idéias, me lembro que me
> foram muito úteis mas como eu disse, eu mesmo não consegui resolver por
> completo.
>

> Primeira coisa, use ohttp://ajaxpatterns.org/, lá tem bastante conteúdo e

> pode ser muito útil. Busque por Security e Authorization em AJAX (http://ajaxpatterns.org/Security_Links). Me lembro (visualmente) que este
> link (http://dev.mixendo.com/wiki/Mixendo_XHR_Security) é interessante.
>  Leia sobre o OAuth, acho que esse é o caminho.
>
> Como não consegui pensar na solução do problema, peço que, se você
> conseguir, comunique para a comunidade, tenho bastante interesse na solução.
> Também estarei a disposição, levei tanta porrada desse assunto que tenho uma
> certa experiência
>
> Abraços.
> --
> Joao Jose Pedrini

> joaojosepedr...@gmail.com

[Paulo Coutinho]

Achou alguma solução interessante?

Eu estou tentando criar um sistema de API simples pro meu portal, para uma idéia inovadora que eu pelo menos não vi em nenhum outro site, mas por enquanto é segredo de estado para ninguém roubar a idéia.

Mas como preciso fazer uma API que vai acessar dados internos do sistema, bate exatamente com seu problema.

Preciso permitir que o usuário faça POST ou GET para enviar algumas informações para a conta dele e o que eu tinha pensado foi uma solução que o @max descreveu, você faz o login e recebe de volta um token, esse token fica numa tabela de acessos para um usuário determiado, juntamente com o IP.

#1
Usuario -> [chama: url/login/entrar, envia: usuario/senha]
Servidor <- [valida e cria token, grava na tabela acessos: usuario_id, token, ip, devolve: token]

#2
Usuario -> [chama: url/servico/gravar, envia: token, dados_exemplo]
Servidor <- [valida token, valida na tabela de acessos(token e ip), grava dados recebidos, retorna OK ou ERRO]

#3
Usuario -> [chama: url/logout, envia: token]
Servidor <- [valida token, valida na tabela de acessos(token e ip), grava dados de logout, exclui token da tabela de acessos]


Acho que essa seria a solução perfeita para algo simples.

2009/10/30 Neves <marcos...@gmail.com>

--
Atenciosamente,
Paulo Coutinho.
Blog: www.prsolucoes.com/blog
Site: www.prsolucoes.com
Msn:  pa...@prsolucoes.com

[G. Sobrinho]

O Authlogic tem isso implementado, não tem? Single Access Token ou coisa parecida o nome, você tem um token pra seu usuário acessar sem senha. Só com o token.

2009/11/1 Paulo Coutinho <pa...@prsolucoes.com>

[Luiz Claudio Garcia]

Tendo como premissa que tu irá fazer deploy no apache com mod_rails, a autenticação provida pelo apache não serviria?
http://httpd.apache.org/docs/2.2/howto/auth.html

Abraçoo


--
====================
---------
Luiz Cláudio Garcia
TRE-RS

2009/10/29 Neves <marcos...@gmail.com>

[Joao Jose Pedrini]

Acho que o problema é um pouco mais abaixo que isto, pelo menos comigo foi.

Temos que lembrar que essas API's que acessam via Javascript, fazem requisições diretamente, do usuário para o servidor do serviço, não passa pelo servidor do cliente (no meu caso eu não queria instalar um proxy ou coisa do gênero no servidor do cliente). Só isso é o suficiente para dificultar tudo. 

Métodos de Sessão são válidos, a utilização de token deve ser com certeza o caminho para solucionar o problema. Só que, num serviço como este, é importante validar que o usuário está acessando de uma página válida, não está fazendo uma requisição de um site diferente. Se o método de sessão não fizer essa validação, não interessa. 

Esta validação é importante para serviços que cobram por acesso e/ou necessitam de auditoria. 

Bem, não estou mais procurando uma solução mas caso alguém consiga ficarei bastante feliz.

Abraços

[Vinícius]

Acho que o OAuth faz tudo e mais um pouco do que vc precisa.

> joaojosepedr...@gmail.com