Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loop after error on ChangePrimaryKey #220

Open
gentee opened this issue Apr 21, 2016 · 1 comment
Open

Loop after error on ChangePrimaryKey #220

gentee opened this issue Apr 21, 2016 · 1 comment
Labels

Comments

@gentee
Copy link
Collaborator

gentee commented Apr 21, 2016

Проблема состоит в том, что ошибка при смене ключа может приводить к зацикливанию входа на страницу. Мне не удалось получить такую ситуацию в результате правильных действий, но в результате некоторых манипуляций зацикливание я получал. Не могу 100% утверждать, что описанное ниже истина, но по крайней мере очень похоже на правду.

Причина складывается из двух вещей.

  1. После ошибки при смене ключа у нас остается новый ключ в таблице my_keys со статусом my_pending. По хорошему, его наверно нужно удалять в Rollback функции. Но так как решение второго пункта обходит эту ситуацию, поэтому останавливаться на этом моменте не будем.
  2. Рассмотрим таблицу my_keys после ошибки. Самый первый ключ имеет block_id = 0 и статус approved. Новый ключ после ошибочной транзакции имеет тоже block_id = 0 и статус my_pending. Теперь рассмотрим функции GetMyPublicKey и GetMyPrivateKey. Они имеют запросы вида

db.Single("SELECT private_key/public_key FROM " + myPrefix + "my_keys WHERE block_id = (SELECT max(block_id) FROM " + myPrefix + "my_keys).

SELECT max(block_id) FROM " + myPrefix + "my_keys возвратит у нас 0 и получается запрос

SELECT private_key/public_key FROM " + myPrefix + "my_keys WHERE block_id = 0.

То есть запрос получается неопределенный
На усмотрении движка БД может вернуться как approved запись, так и my_pending, которая имеет невалидный ключ. Чаще видимо возвращается первая запись,

При замене этого запроса на запрос

SELECT private_key/public_key FROM " + myPrefix + "my_keys WHERE status!='my_pending' order by block_id desc limit 0,1

Всякая двусмысленность исчезает и будет возвращаться последний одобренный ключ.

Зацикливание в нащем случае похоже как раз и просиходит при возврашении невалидного ключа в условии content.go

if (string(utils.BinToHex(userPublicKey)) != sessPublicKey && len(myPrivateKey) == 0) || (countUsers > 0 && len(myPrivateKey) > 0 && !bytes.Equal(myPublicKey, []byte(userPublicKey))) {

Похожи запросы с (SELECT max(block_id) FROM " + myPrefix + "my_keys встречаются еще в нескольких местах и по хорошему там тоже нужно исправить для избежания подобных ситуаций.

@gentee
Copy link
Collaborator Author

gentee commented Apr 22, 2016

Я исправил ошибку с зацикливанием. Я меня на тестовом примере зацикливания в этом варианте нет. Там еще нужно было private_key удалять из my_keys, если при автоматическом логине была ошибка .
А по самой причине ошибки при смене ключа пока не стал менять.

@c-darwin c-darwin added the Bug label Apr 22, 2016
gentee added a commit that referenced this issue Apr 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants