Closed lucca65 closed 2 years ago
auth
for web logging, session
for logged in session. I am thinking for future devices, we can create new contexts by adding the device as a suffix, e.g auth-mobile
and session-mobile
?Hey @lucca65 regarding the decoupling of eosjs wrapper. I would like to suggest that we incorporate the decoupling refactor within the same PR as the session table.
Mainly due to the fact that the decoupling wasn't a major refactor as anticipated.
we can create new contexts by adding the device as a suffix
Hmm, maybe we can simply store their user-agent information, or other stuff we found on the headers, and filter from there. I think it would only be useful to have something like this if we need to treat them differently... any ideas?
@lucca65 I need your advise with this edge case here, when the client doesn't save their session token after sign in.
One solutions is to allow phrase creation even if a session already exists.
This prevents the client from creating a new phrase because the session stills exists from sign in.
Hmm, why not? We can have several sessions on the same user, that's the case when they have multiple devices
As discussed on the call I will address in my second PR to improve-auth
. Which will solve the above case and allow a single user to create sessions across multiple devices.
Dentro da função Accounts.verify_pass/2
É criada para solicitar um login novo e expira automaticamente.
> ecc.sign(frase, '5JZAmtKZ9fwgFHfnCKKxdamV8dwUdoixNAPsLNedQdeteWoga7y')
< "SIG_K1_K21huz3XyG3Z1pJ1731ieEaPyWUGDDuoxNAxd9imxcnEYpDd6EVH23aPj7x5GYAFVSrohzR6KQyMfEEnm8x77Toxy1CS25"
> sig = ecc.sign(frase, '5JZAmtKZ9fwgFHfnCKKxdamV8dwUdoixNAPsLNedQdeteWoga7y')
< "SIG_K1_K21huz3XyG3Z1pJ1731ieEaPyWUGDDuoxNAxd9imxcnEYpDd6EVH23aPj7x5GYAFVSrohzR6KQyMfEEnm8x77Toxy1CS25"
> ecc.verify(sig, frase, '')
< AssertionError: Invalid public key
> ecc.verify(sig, frase, 'EOS54m7kANU7F635hGqjfaiCbkB2JviXH55UfSeGajQmgdWvC5S16')
< true
> ecc.verify(sig, frase, 'EOS5xMPivcfHXCUQoYhMvExMZcMxESHsiZf57Rt6wyEm71uJEE7mm')
< false
Authentication Phase 2
Now with the basic security implemented, we now need to improve the next phase of our authentication update, this next batch should allow us to have signature verification as a password.
New features
We still need some steps to allow greater security and flexibility!
I feel like the
3
feature still needs more maturation and discussions on how the general idea worksStory Update
Eu como usuário Quero me autenticar no sistema Para utilizar partes não públicas (offchain) da aplicação
Telas
N/A
Casos de uso
Dado um usuário fazendo login Quando colocou sua chave privada/12 palavras Então o frontend guarda essas chave privada/12 palavras na Wallet do browser
Dada um usuário ainda não autenticado Quando já tem a chave privada/12 palavras salvas na Wallet Então o frontend solicita uma nova sessão
Dada uma nova solicitação de sessão, gerada pelo backend Quando o frontend a solicitar Então é criado no banco uma nova sessão ainda não autenticada, com um Time to Live de 30 segundos (análogo a tabela
veil_requests
do NatusDado que o frontend recebeu a nova sessão Quando o front assinar e mandar um
signIn
contendo a assinatura da frase Então o backend verifica se a frase foi assinada usando a chave pública do dono da conta que fez a solicitaçãoDado uma sessão já logada Quando o plug (
CambiatusWeb.Plugs.SetCurrentUser
) for verificar se o usuário já está logado e constatar que o token foi atualizado faz mais tempo do que está parametrizado Então dá erro de token expirado