| Лучшие (260) | Сообщества (407) | Блоги (188) | Новые (328) |
Выявил такую особенность, что хеширование происходит на стороне клиента при помощи JavaScript, затем результат посылается на сервер. JavaScript включен — значит хеширование произойдет, выключен – значит нет. В итоге мы получаем два вида записи пароля, в хешированном варианте и аналогичном.
Какие могут быть последствия: 1. Если пользователь зарегистрировал аккаунт с отключенным JavaScript-ом, то и в дальнейшем ему придется авторизоваться так же с отключенным, а иначе авторизация не произойдет. 2. Если пользователь регистрировал свой аккаунт в IE6, а потом перешел на более современный браузер, то он столкнется с проблемой авторизации, так как IE6 в полной мере не поддерживает JavaScript-ы из Сogearа.
Вот такие пироги, однако.
Какие могут быть последствия: 1. Если пользователь зарегистрировал аккаунт с отключенным JavaScript-ом, то и в дальнейшем ему придется авторизоваться так же с отключенным, а иначе авторизация не произойдет. 2. Если пользователь регистрировал свой аккаунт в IE6, а потом перешел на более современный браузер, то он столкнется с проблемой авторизации, так как IE6 в полной мере не поддерживает JavaScript-ы из Сogearа.
Вот такие пироги, однако.
Наглядная схема неисправности недоработки:
Не критично, конечно, но всё равно не правильно. Например, в биллинговой системе abills, для генерации пароля отведено отдельное поле. Может стоит поступит так же? Вроде, нет события от которого оттолкнуться и вернуть полю состояние озвездочивания.
И ещё, рас уж по пути. Мне кажется было бы не плохо предоставить пользователю возможность смены адреса электропочты для подтверждения регистрации (хотя бы один раз на следующей страничке), на случай если он ошибся при вводе. Случай редкий, но один раз ошибся и логин надо придумывать другой. Создание повторного проверочного поля для ящика нужного эффекта не даст — пользователи ленивые и будут копипастить, так что считаю что первый вариант более правильный, что думаете?
ps: пусть это не тянет на баг, но более подходящего раздела не приглядел.

Не критично, конечно, но всё равно не правильно. Например, в биллинговой системе abills, для генерации пароля отведено отдельное поле. Может стоит поступит так же? Вроде, нет события от которого оттолкнуться и вернуть полю состояние озвездочивания.
И ещё, рас уж по пути. Мне кажется было бы не плохо предоставить пользователю возможность смены адреса электропочты для подтверждения регистрации (хотя бы один раз на следующей страничке), на случай если он ошибся при вводе. Случай редкий, но один раз ошибся и логин надо придумывать другой. Создание повторного проверочного поля для ящика нужного эффекта не даст — пользователи ленивые и будут копипастить, так что считаю что первый вариант более правильный, что думаете?
ps: пусть это не тянет на баг, но более подходящего раздела не приглядел.
Последнее время на сайте часто стала появлятся вот такая ошибка, когда входишь в блог:
A PHP Error was encountered
Severity: Notice
Message: Uninitialized string offset: 64
Filename: models/user.php
Line Number: 338
Вопрос:
С чем связанно особое отношение к никам состоящим из одних цифр? Сначала я подумал, что движок воспринимает логин из цифр как регистрацию на сайте бота, но когда понял, что под таким логином можно постить, то задался вопросом: если движок так настроен, что логин из цифр классифицируется как бот, то зачем вообще регистрировать такие ники?
С чем связанно особое отношение к никам состоящим из одних цифр? Сначала я подумал, что движок воспринимает логин из цифр как регистрацию на сайте бота, но когда понял, что под таким логином можно постить, то задался вопросом: если движок так настроен, что логин из цифр классифицируется как бот, то зачем вообще регистрировать такие ники?


admin → блог Nepofigist / О Cogear: немного эмоций 11
JiLiZART → Новости / Релиз фреймворка задерживается 173
Oleksandr → Обновления / Loginza 19
Ramir → Запросы, предложения и планы / Оптимизация Cogear One 3
Ramir → блог aesteral / Сжатие JavaScript и CSS 2
IceDragon → блог IceDragon / Тестирование cogear2 на реальном хостинге 1