LINUX.ORG.RU
решено ФорумAdmin

Юморной SQLite

 


0

1

Привет, эксперты. Столкнулся со странным поведением sqlite. Суть такова: запрашиваю данные юзера «user» из базы, юзера находит и данные отдает, в том числе и хэш пароля. Тут же копирую этот хэш и говорю, покажи юзеров с таким хэшем, sqlite отвечает, что нет таких. Как это возможно? Может я что-то не так делаю?

sqlite> pragma table_info(users);
0|id|int|0||1
1|name|text|1||0
2|password|text|1||0
3|type|int|0|0|0
4|blocked|int|0|0|0
sqlite> select * from users where name='user';
|user|fb131bc57a477c8c9d068f1ee5622ac304195a77164ccc2d75d82dfe1a727ba8d674ed87f96143b2b416aacefb555e3045c356faa23e6d21de72b85822e39fdd|1|0
sqlite> select * from users where password='fb131bc57a477c8c9d068f1ee5622ac304195a77164ccc2d75d82dfe1a727ba8d674ed87f96143b2b416aacefb555e3045c356faa23e6d21de72b85822e39fdd';
sqlite>

Решил заюзать sqlite в своей программе, соотв., когда из программы добавляю юзеров в базу, все ок, авторизация работает. Но стоит поменять пароль юзеру из своей проги (UPDATE users SET password=хэш_пароля WHERE rowid=ид_юзера), как начинается вышепоказанная хрень — не пускает в прогу, т.к. не может найти юзера по связке имя+хэш.

Выхлоп

.schema users
сюда выложи.

hippi90 ★★★★ ()
Ответ на: комментарий от hippi90
sqlite> .schema users
CREATE TABLE users (id int primary key, name text not null, password text not null, type int default 0, blocked int default 0);
s3rjke ()

На всякий случай добалю, что такое поведение начинается именно после изменения пароля пользователя, т.е. после (UPDATE users SET password=хэш_пароля WHERE rowid=ид_юзера) из самописной проги. Вот вывод для пользователя 'operator', который был добавлен из проги, но не изменялся.

sqlite> select * from users where name='operator';
|operator|3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30abb9e3a6df2ac2c20fe23436311d678564d0c8d305930575f60e2d3d048184d79|1|0
sqlite> select * from users where password='3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30abb9e3a6df2ac2c20fe23436311d678564d0c8d305930575f60e2d3d048184d79';
|operator|3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30abb9e3a6df2ac2c20fe23436311d678564d0c8d305930575f60e2d3d048184d79|1|0
sqlite>
s3rjke ()
Ответ на: комментарий от s3rjke

Голоса из прошлого подсказывают, что использовать = для сравнения строк не очень хорошо, есть like

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

Спасибо за совет, like так like.

В общем, разобрался. Судя по всему проблема возникла из-за особенностей типизации sqlite и моей невнимательности.

При апдейте пользователя я отдавал в качестве пароля байтовый массив, вместо явной строки (криво скопипастил свой же код). А уж во что этот байтовый массив преобразовывался в QSQL-е, а потом в sqlite-e, одному Ктулху известно.

Наверное, там оказывалось либо длинное шестнадцатиричное число, либо BLOB.

s3rjke ()
Ответ на: комментарий от Dark_SavanT

BTW, по этой ссылке выходит, что для точных совпадений как раз луше подходит «=». Врут?

s3rjke ()
Ответ на: комментарий от s3rjke

Не врут. '=' - строгое равенство, 'like' позволяет более гибко строки сравнивать. В твоём случае '=' видимо отваливался где-то на проверках.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

У вас плохие голоса. А в части задачи ТС тем более. Можно «весело и с песней» поменять больше одной записи.
ТС не слушай норкомана.

anc ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

'like' позволяет более гибко строки сравнивать. В твоём случае '=' видимо отваливался где-то на проверках.

Нет, ну реально же норкоман.

anc ★★★★★ ()
Ответ на: комментарий от anc

Я последний раз sqlite в частности и реляционные БД вообще, трогал лет 5 назад и могу только поддержать совет «не слушать наркомана»

Dark_SavanT ★★★★★ ()

Знак переноса строки и прочие весёлые знаки проверял?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.