Para dar início à série sobre o Couchbase Mobile Sync Gateway, começaremos com a compreensão de como autenticar e autorizar usuários em Gateway de sincronização que é o componente intermediário entre os aplicativos móveis e o Couchbase Server.
Por meio do Sync Gateway, há várias maneiras de autenticar a base de usuários do seu aplicativo móvel para autorizá-los a acessar o banco de dados remoto. A partir daí, os aplicativos móveis podem comunicar os dados por meio de replicação, em que os dados podem ter sincronização bidirecional e de vários mestres. Vamos explorar as diferentes Usuários de autenticação mecanismos primeiro.
Autenticação
Autenticação básica de HTTP
O cliente móvel é capaz de se autenticar por meio do Sync Gateway usando um URL de sessão em que é determinado como /dbname/_session ou usando uma sessão baseada em cookies.
|
1 2 3 |
curl -H "Content-type: application/json" -X POST https://localhost:4984/dbname/_session --data "{"name":"userID","password":"pw"}" |
Com as credenciais de usuário fornecidas na solicitação POST do URL da sessão, a validação retornará o seguinte mediante um conjunto correto de usuário e senha
|
1 2 3 4 5 |
{ "authentication_handlers":["default","cookie"], "ok":true, "userCtx":{"channels":{"!":1,"channel1":1,"channel2":1},"name":"userID"} } |
Autenticação plugável
Para o Couchbase Mobile, o método de autenticação do Facebook é uma opção de autenticação conectável em que o Sync Gateway se comunicará com o Facebook para autenticar o token para os clientes. Para que possamos ativar esse recurso, a propriedade de nível superior 'facebook' é definida como true no arquivo de configuração do servidor para a chave 'register' como abaixo.
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "facebook" : { "register" : true }, "databases": { "grocery-sync": { “server”:”https://cbserver:8091”, “bucket":"grocery-sync", "users": {"GUEST": {"disabled": true}}, "sync":`function(doc) {channel(doc.channels);}` } } } |
A partir daí, o cliente móvel pode registrar implicitamente novas contas de usuário, autenticando-as por meio do Facebook com uma solicitação POST para '/dbname/_facebook' e retornar um JSON que contenha:
- token_de_acesso: Token de acesso retornado pelo Facebook
- e-mail: E-mail do usuário
- remote_url: Ponto de extremidade do gateway de sincronização
O nome de usuário da conta é o mesmo que o endereço de e-mail autenticado, juntamente com uma senha aleatória.
Autenticação personalizada
Há algumas vantagens em ter uma autenticação personalizada para o seu aplicativo móvel, pois você não precisa depender de soluções de terceiros, como o método anterior do Facebook conectável. Em geral, há mais trabalho envolvido, pois você precisa manter o serviço que se comunica com o Sync Gateway junto com as respectivas chamadas de ponto final do aplicativo móvel. Isso dependerá do fato de você ter uma base de usuários existente, como um Servidor LDAP ou que o cliente talvez precise ter o recurso para criar uma combinação de nome de usuário e senha.
Para implementar um provedor personalizado em que existe uma base de usuários em uma configuração de servidor LDAP, o aplicativo móvel aponta primeiro para o aplicativo ou servidor de autenticação. O servidor de autenticação é então responsável pela autenticação dos usuários e, depois de autenticar um usuário com êxito, o servidor de autenticação faria uma chamada de API para o Sync Gateway API REST do administrador na segunda etapa, para obter uma sessão válida para esse usuário, enviando uma solicitação POST para '/dbname/_session' endpoint. Esse token de sessão é encaminhado de volta para o servidor de autenticação e, em seguida, devolvido ao cliente móvel. A terceira e última etapa, depois que o aplicativo móvel obtém o token, é comunicar-se diretamente com o Sync Gateway usando o token de sessão para obter todos os dados necessários para o usuário no dispositivo.
Depois de autenticar nossos usuários, é hora de explorar as diferentes Autorização de usuários mecanismos a seguir.
Autorização
Contas: admin_channels
O Sync Gateway permite autorizar que determinados usuários tenham direito a determinados documentos em um banco de dados. Por meio do Arquivo de configuração JSONque define as propriedades do Sync Gateway, podemos usar o recurso 'admin_channels' para ativar uma lista de canais aos quais o usuário tem acesso depois de autenticado. A autorização de um usuário em um canal específico permitiria o acesso de LEITURA do documento:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
{ "log" : [“*”], "databases": { "grocery-sync": { “server”:”walrus:”, “bucket":"grocery-sync", "users": { “alice”: { “disabled” : false, “password”: “password”, “admin_channels”:[“items-alice”] }, “bob”: { “disabled” : false, “password”: “password”, “admin_channels”:[“*”] }, “sync” : ‘ function(doc, oldDoc) { channel(“items-”+doc.owner); } //Add item document to owner’s items channel ‘ } } } } |
No exemplo acima, o canal * Star é um canal especial que fornece privilégios de administração para um usuário específico, Bob, ao qual é concedido acesso aberto a todos os documentos em um banco de dados. Alice, por outro lado, terá acesso ao seu próprio canal de itens, que é específico para a tag 'items-alice' e, portanto, no esquema de autorização, Alice é então autorizada. Para que a autorização ocorra, o campo do proprietário em um documento de item de mercearia precisa ser vinculado à tag O proprietário deve canalizar os itens pessoais de acordo.
A função de sincronização permitirá que os usuários enviem revisões aos documentos, verificando se os usuários estão autorizados a acessar o documento. Isso é feito atribuindo propriedades de conta como 'password' acima no exemplo ou 'roles' aos usuários, onde os usuários autorizados podem acessar o Sync Gateway e controlar seu banco de dados remoto. O 'admin_channel' e o 'password' são duas das propriedades disponíveis Propriedades da conta que pode ser usado para autorizar o acesso do usuário ao banco de dados remoto por meio do Sync Gateway.
Na série de blogs de acompanhamento do Sync Gateway, exploraremos como o 'CanaisPermitir que determinados usuários possam ler um documento no banco de dados e saber como os dados são roteados.
Acho que isso precisa de um pouco mais de detalhes, o POST para o URL público só obtém uma sessão temporária que é melhor excluir