Надёжная авторизация для веб-сервиса за один вечер

image

Предыстория


Осень 2015-ого. Примерно полтора года назад, когда мне случилось стать участником разработки проекта, где пользователей существенно больше пары десятков человек, я наконец-то впервые в своей жизни задумался о надёжности авторизации.

По сути, авторизация — это то, с чего начинается процесс взаимодействия зарегистрированного пользователя с системой (для незарегистрированного пользователя всё начинается с регистрации, и эти два процесса, как вы уже догадались, очень сильно взаимосвязаны). Я внезапно осознал, что во всех проектах, что я делал до этого, с безопасностью всё очень плохо.

Достаточно рассмотреть простейший пример: кто-то подобрал пароль, или человек каким-то образом скомпрометировал его. Конечно, у нас в базе данных хранятся хэши с использованием соли, мы даже настолько продвинуты, что используем только HTTPS… Но это никак не спасёт нас от человеческого фактора.

Что делает в случае взлома грамотная система? Блокирует аккаунт (совсем хорошо — если автоматически, по ряду необычных признаков в поведении пользователя), в дальнейшем предлагая средства для восстановления: привязанный телефонный номер, контрольный вопрос, и т.д. Привязка сотового — отличная мера с крайне высокой надёжностью. К сожалению, у нашего проекта не было на это средств, поэтому приходилось обходиться без этого. Благо, блокировку можно реализовать, посадив человека на специальный почтовый ящик, или даже принимать экстренные звонки на сотовый.

И тут традиционный метод, который применяют многие начинающие разработчики (найденный в книгах, либо в статьях в интернете) даёт осечку. Дело в том, что этот метод предполагает хранение авторизации в сессиях. Это статья не относится к конкретному языку, и справедлива для любой платформы, но я буду иллюстрировать всё на примере PHP.

Стандартная реализация


Итак, сессия в PHP по умолчанию хранится в файле. Её id сохраняется в cookie (если куки отключены — задействуется механизм передачи через адресную строку, если это не отключено в конфигурации). Время жизни такой сессионной куки по умолчанию — до момента закрытия браузера (и обычно его никто не меняет). Поэтому более продвинутые программисты реализуют галочку «запомнить меня», либо реализуют её функционал по умолчанию, без возможности отключить. Что они делают? Просто сохраняют в собственной куке айди пользователя. Но поскольку просто айди хранить как-то уж слишком стрёмно (любой может поставить любое число и получить доступ к произвольному аккаунту), то часто вместе с айди за компанию сохраняют и пароль. В открытом виде.

Если кто-то не понимает, чем это плохо — представьте себе, что у нас пользователь пользуется очень старым, либо очень плохо реализованным браузером. Мы ведь не можем гарантировать, что браузер надёжно шифрует куки? Да и вирусы всякие могут быть у пользователя на компьютере, и в случае особо серьёзной малвари может не спасти и шифровка — зловред может попытаться считать значения прямо из памяти, когда они расшифрованы. Человек, случайно оказавшийся у вашего компьютера в ваше отсутствие — сможет просто скопировать себе все интересующие куки, и в новых браузерах этот процесс стал ещё проще. Дыры в безопасности браузера могут потенциально привести к тому, что ваша кука станет доступна стороннему сайту (да, сейчас это крайней маловероятно, но чем чёрт не шутит).

Ну и самое главное — если у нас SSL используется только при авторизации (а на остальных страницах его решили отключить ради выигрыша в скорости, либо чтобы лучше работало промежуточное кэширование)… То наш пароль всё время передаётся открытым текстом. При каждом запросе. А пароль меняют редко, то есть это некий токен, который имеет долгий срок жизни. А теперь представим себе, что наш трафик кто-то перехватил…

Как быть?


Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.

Первое, что приходит на ум — хранить вместо пароля хэш от него. Это не особо поможет, если кто-то перехватит трафик, и не поможет при краже кук. Но вот в ситуации «кто-то открыл настройки и прошёлся по кукам, пытаясь запомнить значения» — сильно усложнит жизнь злоумышленнику.

Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).

Но если пароль всё же утёк — мы по-прежнему бессильны. Даже сменив пароль через форму восстановления либо изнутри системы — взломщик останется залогинен, пока не закроет браузер. Ведь в основе авторизации у нас всё ещё лежит сессия.

Можно, конечно, на PHP получить id сессии при логине, записать его куда-то в базу, а при сбросе пароля стартовать по очереди все сессии с айдишниками из базы и делать session_destroy()… Возможный вариант, но не обязательно следовать ему.

Итак, мы сформулировали основной список требований к нашей системе:

1. Быть простой в реализации
2. Желательно не зависеть от используемой серверной платформы
3. Позволить «выкинуть» взломщика из системы, завершив все открытые сессии, либо некоторые из них (на основе браузера/операционной системы/времени логина)
4. Видеть список всех своих открытых сессий в системе, просматривать его
5. Максимально затруднить атаку в случае отсутствия SSL (например, открытый Wi-Fi)
6. Не создавать неудобств легитимным пользователям

Приступаем к работе


Перво-наперво создадим в нашей базе данных (будем считать, что мы используем реляционную СУБД) таблицу для хранения сессий. Наших сессий (не путать с PHP-шными!). Таблица будет иметь следующие поля: id, user_id, ip, user_agent, time. В качестве времени будем хранить время создания сессии. Можно хранить и время последнего доступа, но вскоре мы увидим, что это избыточно, и можно к этому прибегнуть лишь в рамках денормализации, чтобы ускорить выборку данных. Создаваться сессия будет в момент авторизации, а также при регистрации (мы хотим, чтобы после регистрации пользователю не приходилось заполнять форму логина, и тут же авторизуем его). Также создадим вторую таблицу — log, с таким же набором полей. Туда будем добавлять запись при каждой авторизации (через форму входа или по кукам).

Теперь мы можем хранить на клиенте id сессии, и сверять его с базой. При этом сервер может проверить, что у нас совпадает юзер-агент и IP. Если хотя бы что-то одно не сходится — считаем, что пользователь не авторизован, и направляем его на страницу логина.

Но этого как-то мало — IP клиента взломщик может знать (и если он перехватывает трафик, то уж точно его знает), то же самое касается юзер-агента (который вообще получить не составляет никаких проблем). Нам хотелось бы хранить в cookie не пароль, а некую производную от пароля, привязанную к сессии… то есть к юзер-агенту и IP. Соответственно, если что-то стало отличаться — доступ прекратится. Поэтому, как вы уже догадались, разумно использовать хэш от этих переменных, и сохранять в куке его. При этом просто посмотрев на хэш, взломщик не только не сможет узнать пароль, но даже точно определить, какие именно компоненты были использованы при его создании (и с какими модификациями).

Создадим в таблице сессий ещё одну колонку — hash. Будем использовать её для хранения хэшей наших сессий.

Вопрос удобства


Но тут мы сталкиваемся с другой проблемой. Клиент может переключаться между разными IP (как минимум между домашним Wi-Fi и 3G в дороге, а ещё рабочим защищённым Wi-Fi, как пример). И было бы очень негуманно заставлять его вводить заново логин и пароль каждый раз при смене IP адреса. Как быть, хранить в куке целый список хэшей? При запросе на сервер отсылать его? Можно, но это несколько усложняет реализацию. Кроме того, это раздувает размер куки (при том, что нам основную часть времени может требоваться всего один хэш, мы будем хранить все когда-либо использовавшиеся), а при очистке кук мы (как пользователь) потеряем их все, и опять придётся с каждого IP адреса вводить пароль вручную.

Что, если привязать хэш только к юзер-агенту? Можно, но это существенно снизит безопасность. Нам нужен компромиссный подход.

Делегирование полномочий


Давайте попробуем создать отдельный модуль. Назовём его совершенно бесхитростно — security.php, и оформим как отдельный скрипт. Будем подключать его ко всем закрытым страницам нашего проекта в самом начале. Внутри этого файла будем анализировать некие условия, а по итогам его работы выставлять специальный флаг в 0 или 1. Пусть этот флаг будет храниться в переменных сессии (массив $_SESSION в PHP).

Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!

Разобьём начальную стадию нашего внешнего скрипта (это тоже можно вынести в отдельный файл, но в данный момент это не важно) на два этапа. На первом мы смотрим, установлена ли обычная сессия PHP. Если нет — сразу перебрасываем пользователя на форму авторизации. Но форма при загрузке проверяет наличие кук, и если кука с хэшем нашей сессии существует, и хэш совпадает с ожидаемым (хэш-функция от пароля* и юзер-агента), то ставим переменные сессии (в первую очередь user_id), делаем запись в таблицу log, и обратно перебрасываем пользователя туда, откуда он пришёл (адрес раздела для возврата разумно передавать прямо в ссылке). Итак, если нет PHP-сессии, но есть куки, и куки соответствуют браузеру — пользователь залогинен.

Примечание
Сервер, конечно же, не знает пароль. Он хранит хэш и соль для его получения. На самом деле, токен для cookie вычисляется как md5($password_hash.$user_agent), то есть это уже хэш от хэша.

Теперь рассмотрим вариант, когда сессия есть (после того, как пользователь залогинен по паролю из формы или по кукам, он тоже попадёт на этот шаг). И вот тут вступает в игру наш скрипт security.php. Вот его код:

<?php

if ($_SESSION['security_check'] == 0) {
   $user_id = $_SESSION['user_id'];
   $n = (int)mysql_result(mysql_query("SELECT COUNT(*) FROM `sessions` ".
            "WHERE `user_id`=".$user_id." AND `ip`='".$_SERVER['REMOTE_ADDR']."' ".
            "AND `user_agent`='".mysql_real_escape_string($_SERVER['HTTP_USER_AGENT'])."' ".
            "AND `hash`='".preg_replace("/[^0-9a-f]/", "", $_COOKIE['auth'])."'"), 0);
   if ($n == 0) {
      header("Location: /login?act=logout");
      exit();
   } else {
      $_SESSION['security_check'] = 1;
   }
}

//$n = mysql_result(mysql_query("SELECT COUNT(*) FROM `banned` WHERE `ip`='".$_SERVER['REMOTE_ADDR']."'"), 0);
//if ($n > 0) $_SESSION['security_check'] = 0;

?>

Если нам нужна система банов — можно раскомментировать последние две строки. И не забываем, что чтобы не произошло бесконечного зацикливания, в скрипт авторизации проверку на бан тоже надо включить!

Скрипт прост как дважды два. Мы проверяем наличие сессии с нашими текущими параметрами и нашим текущим хэшем. Если что-то не совпало — нас попросят пройти повторную авторизацию через редирект. И вот тут происходит самое вкусное. Если у нас поменялся только IP — мы пройдём проверку, для нас создастся новая сессия, если её нет для этого IP (этот момент надо включить в код авторизации), и создастся новая кука.

Если у нас поменялся браузер (угнанная кука) — придётся вводить пароль, которого у взломщика нет, иначе зачем ему воровать куки. При этом IP скорее всего будет другим, но может быть и тем же (взломщик находится с нами в одной локальной сети). В случае, когда взломщик в одной сети с жертвой, и имеет тот же юзер-агент — к сожалению, мы никак не сможем отличить его от настоящего пользователя. Привет, беспарольный Wi-Fi.

Если поменялся только хэш (поменяли куку вручную? побились файлы на жёстком диске?) — придётся авторизоваться заново, ничего не поделать.

Наконец, можно очень эффектно моментально отключить доступ к аккаунту. Для этого даже не обязательно удалять строку с сессией. Достаточно удалить/поменять/добавить один символ в хэше (последнее поле). Пример из жизни — если легитимный пользователь по счастливому стечению обстоятельств первым успеет воспользоваться кнопкой смены пароля в кабинете — взломщика выкинет, причём при первой же перезагрузке страницы. У настоящего пользователя уже будет новая кука (в хэше будет использован новый пароль), старые сессии будут полностью удалены из таблицы, а новая сессия создана с новым хэшем. А взломщик останется со старым невалидным хэшем, который не пройдёт проверку в security.php. При первом же непрохождении будет сброшена сессия PHP, и выполнен редирект на авторизацию. Которую, опять же, нельзя пройти, имея неактуальный хэш от старого пароля.

Всё хорошо?


Почти. Данная система по-прежнему не защищает от кражи хэша из кук при открытом канале и отсутствии SSL. Кроме того, сложно обеспечить своевременную блокировку, если доступ к аккаунту утерян (особенно если взломщик уже сменил пароль). В этом случае очень помог бы сброс пароля через смс-команду с привязанного телефона — но для этого уже нужна возможность принимать и отправлять смс. А если она есть — то можно сразу внедрить двухфакторную авторизацию, которая снимет массу проблем. Но не проблему с необходимостью в SSL — поскольку всё равно результатом любой авторизации является получение некого токена доступа, работающего ограниченное время. И этого времени может быть достаточно, чтобы сделать от нашего имени что-то, что нам не понравится.

Данный код можно, наверное, сделать ещё лучше и надёжнее. Если у вас есть по этому поводу соображения — пишите их в комментарии. Пока что система зарекомендовала себя с очень хорошей стороны, и была использована уже минимум в трёх проектах, два из которых имеют массовый доступ.
Share post

Comments 354

    +8
    AND `hash`='".$_COOKIE['auth']
    

    sql injection
      0
      Спасибо, и правда глупо получилось)
      +7
        "AND `user_agent`='".$_SERVER['HTTP_USER_AGENT']."' ".
      

      sql injection
        0
        faceplam(2)

        Хотя это конечно очень не очевидно для стороннего человека, что такое вообще есть. Не зная исходников :)
          +2
          https://en.wikipedia.org/wiki/Security_through_obscurity
            –3
            Примерно знал про это, хотя эту статью не читал ещё раньше. Здесь основной принцип был не в этом. Я просто к тому, что мало кому придёт в голову пихать SQL-инъекцию не в форму ввода или GET-параметр, а в куку. Да ещё именно в эту. Не зная исходников :)
              +5
              мало кому придет в голову пихать инъекцию руками, а стандартный софтв Кали пихает сам во все вохможные и невозможные места
                –3
                Не слышал про такой, но согласен, что лучше не допускать ни одной уязвимости. Тем более, когда тебе уже явно на неё показали. Исправлю этот момент.

                На самом деле, сильно код не поменяется. Ну будет mysql_real_escape_string($_SERVER['HTTP_USER_AGENT']). Читать сложнее, пример же больше как учебный писался. Но в целом да, лучше сделать так. Согласен абсолютно здесь.
                  +18

                  Примерно знать про security through obscurity, не слышать про kali, но при этом писать обучающую статью "Надежная авторизация". Вы серьезно?


                  А вообще, для начала можно было открыть код любого нормального фреймворка и посмотреть, как реализована авторизация в нем.

                    +1

                    Но ведь интереснее попытаться придумать самому :) Если посмотреть, как сделано у других — есть шанс, что лучше придумать уже не получится. И в итоге просто скопируешь один в один.

                    • UFO just landed and posted this here
                      0

                      Статья не совсем обучающая, и она скорее рассчитана на самый начальный уровень… Я ни на что и не претендую как бы

                      0
                      Прочтите — Symfony день 1. Там есть момент:
                      Наверное вы читали подобное предупреждение:
                      «Не забудьте добавить валидацию и проверки на ошибки в реальном приложении.»
                      или
                      «Безопасность отдаётся на личное изучение читателя»
                      или
                      «Конечно, Вам придётся писать тесты»

                      Этим и отличается хороший учебный материал от плохого.
                        0

                        А я всегда выполняю проверки на ошибки. То, что тут их не оказалось — это не система. А разовый недосмотр :)


                        Про безопасность — тоже очень мудро, пока сам шишек не набьёшь, не поймёшь, что нужно проверять, когда и зачем. Тоже кстати был опыт, на своих ошибках учился.


                        Насчёт тестов — пока как-то судьба миловала. Видимо, проекты не столь большие и сложные, обхожусь без них. Но иногда приходится прибегать к ухищрениям и разбивать алгоритм на составные этапы, тестируя каждый из них в отдельности, и лишь потом переходя к следующему, иначе просто велик риск получить полностью нерабочий код, отчаяться и опустить руки.

                      • UFO just landed and posted this here
                          +2
                          Оно уже deprecated и выпилено из PHP 7.
                          • UFO just landed and posted this here
                              0
                              PDO всё же удобнее: легко менять драйвер без внесения изменений в код.
                              • UFO just landed and posted this here
                                  –1

                                  А зачем Вам вообще менять драйвер? Обычно БД выбирается один раз при старте проекта, и больше не меняется уже. Если вы, допустим, фрилансер — то и вовсе наверное одну и ту же предпочтёте использовать, ибо так проще. Соответственно, и драйвер будет один и тот же. Разве может быть драйвер быстрее и надёжнее нативного?

                                    +1
                                    Обычно БД выбирается один раз при старте проекта, и больше не меняется уже.

                                    Обычно это работает если СУБД выбирается из принципа упрощения разработки, чтобы не морочиться с хранением и получением структурированных и не очень данных по принципу "без СУБД надо будет много кода писать, а эту СУБД я лучшего всего знаю". Если же СУБД выбирается по требованиям к проекту типа "обеспечить максимальную скорость записи с синхронной репликацией в дата-центры по всей Земле с соблюдением транзакционной целостности на любой момент времени", то проект может переезжать по нескольку раз с одной СУБД на другую в зависимости от того, какая здесь и сейчас показывает лучшие результаты (недавно показательный перевод поста про переезд Uber на MySQL был).


                                    При одном условии это делается без особых проблем — код работы с базой максимально переносим, переезд не будет сравним по трудозатратам с написанием с нуля, а то и больше.

                                    • UFO just landed and posted this here
                                        –2

                                        ORM нужны больше для отделения данных от storage layer, то есть мы оперируем не запросами к базе, а объектами, а те сами себя получают и сохраняют (через ещё одну прослойку), если я правильно понимаю. Но это больше делается ради привычности кода (для тех, кто любит ООП) и ради общей красоты.


                                        А переезд из-за того, что возможностей движка мало… Я не знаю. Наверное, должен быть реально гигантский проект, чтобы упереться в потолок того же MySQL. Плюс есть MariaDB, которая несколько производительнее, но работает с тем же API абсолютно. И потом, многое можно решить, взяв более мощное железо, либо докупив серверов. Это может оказаться сильно выгоднее, чем переписывать код.


                                        И вообще, прелесть ORM я понимаю, прелесть PDO — вообще нет.


                                        И что, переписывать весь код?

                                        Таки да! Создать отдельную ветку и переписывать все вызовы к базе. Не весь проект конечно с нуля переписать, но процентов 30-40. Либо создать родительский абстрактный класс или интерфеййс, от него отнаследоваться, и старую реализацию оставить параллельно с новой. Вот поэтому и не надо такие переезды делать, себе дороже :)


                                        И я бы не сказал, что PDO сильно медленнее нативного.

                                        Ну чуть-чуть всё же медленнее должен быть. Он ведь обращается к базе не напрямую, а через ещё один драйвер по сути.

                                        • UFO just landed and posted this here
                                –2

                                И правда смотрится изящно. Плюсанул бы вам, жаль не могу :)

                    +13
                    авторизация -> аутентификация
                    в целом рановато вам еще рассуждать о безопасности, на данный момент статья — набор вредных советов из 1999 года.
                      –7
                      Ну почему вредных. Вредный совет — хранить пароли в плейнтексте, да ещё в файлах. Или полагаться исключительно на сессии (это советовали не в 1999-ом, а ещё в 2007-2008 во всех учебниках начального уровня).
                        +18
                        Очень много бед в ИБ идет из-за непонимания. Непонимания механизмов, процессов, рисков. В вашем случае видна нехватка знаний в теме «безопасность веб приложений», есть перекос в сторону «кражи кук по вине дыры в безопасности браузера», но при этом приводите в примере sql инъекции. Это намекает на незнание темы и на неправильную оценку рисков по теме «безопасности веб приложений», на которую вы подвязались учить других. Чревато это тем, что часть людей(не берем в счет те приложения, где вы уже успели внедрить вышеприведенный код — там отдельные риски), которые точно также не понимают нюансов, стянут код у вас(просто нагуглят по запросу «Надёжная авторизация для веб-сервиса за один вечер») и влепят к себе. А достаточно было хотя бы просто не учить тому, в чем сами пока не являетесь специалистом.
                          –9
                          Ну насчёт вышеуказанных замечаний — я уже внёс исправления. С User-Agent вообще спорно: туда точно никто в трезвом рассудке не станет пихать куски SQL-запросов. Тем более, не уверен, что даже инъекция в этом случае даст возможность взломщику прочитать структуру БД (только убить там все данные, но это не так интересно коммерчески).

                          Наконец, я рассуждал про безопасность на уровне браузера. Не все браузеры дают менять юзер-агент, а те, что дают — там надо ещё найти, где это делается. Всё же такой код безопаснее стандартного варианта. Не забывайте, что взломщик не знает исходников.
                            +11
                            Ну вот про это и речь — вы просто не понимаете риски и опасность того, что вы пишите. «С User-Agent вообще спорно». Для вас подмена юзерагента без исходного кода приложения — нечто из рамок выходящее, маловероятное и все такое. Вы по другую сторону барьера, вы не знаете техник атакующего. Для пентестера(и всяких взломщиков в том числе) — один из базовых подходов при backbox тестировании. Просто вот так при анализе веб приложения пентестеры практически сразу же берут да и втыкают кавычки в юзерагент, не пользуясь для этого браузером, а например Burp Suit'ом или Fiddler'ом. Просто так все сканнеры, начиная с Acunetix'a делают тоже самое в автоматическом режиме. Такая уязвимость найдется любым адекватным сканнером уязвимостей.
                              –6

                              Спасибо, не знал. Знал про всякие атаки виде "Slow query", под это даже Antiloris mode был под Apache… Знал про всякие трюки с хитрым экранированием символов в URL… Про User-Agent не знал, каюсь.

                              +4
                              Это было в волшебнике изумрудного города. Сюжет с очень прочными воротами… но в чистом поле…
                              –1
                              +1 солидарен с akirsanov
                            –6
                            А в чём разница этих терминов, не поясните? Я встречал термин «авторизация» очень часто именно в том значении, в котором он применён у меня.
                              +4

                              Идентификация — представление пользователя, "я — такой-то" (юзернейм в форме логина)
                              Аутентификация — доказательство личности идентифицированного пользователя, "и вот секрет, который знаю только я" (пароль в форме логина)
                              Авторизация — проверка прав пользователя на осуществление конкретного действия, "мы верим, что вы "юзернейм", но вы не имеет права на действия, которое пытаетесь совершить" (бан по юзернейму или невозможность редактировать комментарии никем кроме автора и админов)


                              Это если "на пальцах".

                                –3

                                Спасибо, но это уж очень дотошно… Зачем разбивать действие по заполнению простой формы из двух полей на два разных понятия? Насчёт авторизации — я прекрасно знаком и с этим значением термина, да. Проверка прав доступа, уровни, привилегии) Но это из другой области совсем.


                                Смотрите, форму, куда вы вбиваете пароль — в веб всё время называют формой авторизации. Никто не называет её "формой аутентификации", я по крайней мере такого не слышал.

                                  +1
                                  Как правило, обработка такой формы это именно 3 этапа, авторизация, проверка прав — последний. И она из той же оперы, собственно только ради неё и нужны часто первые два, особенно второй.
                                    +1
                                    Тут нет противоречия. Когда вы нажимаете на кнопку «войти» в «форме авторизации», то происходит:
                                    1. Идентификация вас по имени пользователя, которое вы ввели в поле «логин»
                                    2. Аутентификация — проверка, правильный ли пароль был введен в поле «пароль»
                                    3. Авторизация — предоставление доступа в соответствии с вашими правами.
                                    Все логично, так как с точки зрения пользователя он в итоге авторизуется на сервисе для доступа к своим ресурсам. Не писать же теперь «форма идентификации, аутентификации и авторизации», ведь аутентификация и идентификация это в данном случае просто компоненты необходимые для авторизации.

                                    Давайте на хабре будем использовать термины правильно.
                              +3
                              Вы зря используете IP адрес клиента:
                              1. Многие сидят за NAT.
                              2. Некоторые провайдеры используют короткие сессии, выделяя каждый раз новый IP клиенту.
                              3. У клиента может быть несколько провайдеров с балансировкой траффика.
                                –3
                                Абсолютно согласен. Именно поэтому привязка к IP в этой схеме сделана таким образом, как сделана, а не на полную. Вы бы сделали иначе?)

                                Насчёт пункта 3 — не встречал, и даже не очень знаю, как такое реализовать, а 1 и 2 сплошь и рядом, да.

                                Но надо всё-таки понимать, что я не уникальность клиента по IP определяю. ВК ведь тоже IP берёт в расчёт, и при заходе откуда-нибудь из-за границы просит подтвердить номер телефона (раньше просил капчу ввести). Только вчера на эту особенность наткнулся при смене хостинга на заграничный, токен перестал работать, пришлось проходить валидацию.
                                  0
                                  Насчёт пункта 3 — не встречал, и даже не очень знаю, как такое реализовать
                                  методов — десятки. Обобщенно — load balancing.
                                  Да и даже проще: какой-нибудь человек со смартфоном, гуляющей по квартире — может легко метаться между домашней wifi сетью через наземного провайдера и интернетом опсоса — как минимум метания между двумя разными адресами.
                                    –1

                                    Ну так моя система отлично такой сценарий обрабатывает. Редирект-то почти мгновенный, о чём и речь. В вк это всё происходит существенно дольше (но у них и нагрузка совсем не того масштаба, тут наивно сравнивать).

                                +3
                                Очень вредная статья. Доверять заголовкам HTTP нельзя — это в любом учебнике написано. mysql_query — вы серьёзно? Почитайте на досуге.
                                  –4
                                  Вредная в чём? Похоже на субъективные придирки. Да, инъекции — зло, но в статье речь не про работу с MySQL была, и не про обработку входных данных.

                                  Суть-то вообще не в этом. А как сделать авторизацию, работающую по лучшим принципам, так сказать. С ведением логов заходов, возможностью «прибивать» сессии на разных устройствах, и прочее.

                                  А что с mysql_query не так? Стандартная функция для запроса к mysql, вроде как.
                                    +1
                                    Новички, прочитав в заголовке «Надёжная...» могут подумать, что здесь описаны сорт оф лучшие практики, а это не так. Логгирование — это отдельная тема, она может и должна рассматриваться вне рамок авторизации/аутентификации. С mysql_query очень не так, хотя бы потому что
                                    Warning This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used.
                                      –4
                                      Ну так предложите практику лучше, я же совсем не против. Как же принцип «отрицаешь — предлагай»? MySQLi может и лучше, я в этом и правда не очень силён, но текст, опять же, не об этом. «Deprecated in 5.5» — совершенно не помеха, когда по функциям за глаза хватает версий 5.3 — 5.4. Но даже в 5.6 расширение mysql работает, к слову, если подключить.
                                        +2
                                        Предложение может быть таким: убить терапевта, рекомендующего садится на огурцы и выписывающего рецепты на лошадиные дозы фуфломицина -)
                                          –3

                                          Так а в чём огурцы-то? Вот вы говорите, в таком-то фреймворке/CMS реализовано лучше. Так расскажите, в каком, и чем именно лучше, давайте обсудим. Надо позицию ведь хоть немного аргументировать.


                                          И я не очень уверен, что все минусующие самостоятельно за вечер написали бы более грамотную реализацию (не глядя в сторонний код).

                                            +1
                                            Огурцы в том, что предложенная и заявленная «панацея» оказалась не то чтобы ненадежной, а просто дырявой.
                                            Все. На этом уже надо ставить точку.

                                            Кстати половина минусующих может быть вообще не программисты, а специалисты по безопасности, которые не пишут код -)
                                              –2

                                              А в чём дыры-то? Отсутствие вызова mysql_real_escape_string в паре мест (учитывая, что это просто не пришло в голову, о другом были мысли при разработке)? Ну это уже слишком толсто, ребят. Не про это ведь текст. Или вообще никто не читает, а только комменты почитать заходят?

                                                +1
                                                Дык в чем проблемы с лечением огурцами по Малахову? Если это совместить с занятиями спортом, прививками и лекарственной терапией — тож будет эффект =)
                                                  –2

                                                  Потому что огурцы вредны. А данный код, если без инъекций — вроде как не особо… Хотя может, я ещё чего-то не учитываю)

                                                    +1
                                                    Дык огурцы, если их кушать — полезнее чипсов даже.
                                                    А так — да, первое — инъекции, второе — привязка к ip

                                                    В итоге шикарная яичница, только яйца просрочены и масло прогорклое…

                                                    Хотя про огурцы я конечно погорячился, они стоят на втором месте после воды по причине смертности… ведь все умершие хоть раз но ели огурцы…
                                                      –1

                                                      А с привязкой что плохого? Она с одной стороны позволяет сработать как некоторый триггер ("айпи поменялся — значит, что-то изменилось, повод перепройти авторизацию/аутентификацию"). Но при этом это не принуждает вручную заполнять заново форму.


                                                      Вы никогда не замечали, что если взять телефон с открытым в браузере вк, выйти из дома, отключившись от вайфай, пройтись по улице, а потом обновить страницу — то у вас будет 1-2 редиректа с передачей в GET-параметре какого-то хэш-кода? И не говорите после этого, что там нет привязки по IP. Ещё как есть :)

                                                  +1
                                                  Если б использовали \PDO, то к вашему коду на порядок меньше придирались.
                                                    –3

                                                    Я почитал специально про PDO. Про синтаксис со знаками вопроса, как в JDBC на Java (в Android и Spring, к примеру). Знакомо. Но как по мне, удобства это не прибавляет.


                                                    Пишут, что там автоматически производится экранирование, и таким образом защита от инъекций идёт из коробки… Согласен, так проще, чем каждый раз вручную. Зато вручную контроля больше. Можно более жёсткие преобразования делать над входными данными, чем просто экранирование.


                                                    Нет, никто не мешает совместить это с PDO, но производительность чуть просядет, если преобразование делать дважды для каждого аргумента.


                                                    Ну и на самом деле, меня просто так учили. В хорошем учебнике от Bhv-Петербург по PHP5, который ещё 2005 года издания, вроде (я его читал в 2006-2007) использовалось только mysql расширение. И оно мне очень нравится своей простотой и интуитивностью, чего уж там.


                                                    К слову, я долго гуглил, и не нашёл серьёзных "дыр" в нём, разве что менее богатый функционал и отсутствие новых функций вроде поддержки транзакций. Но там для начала движок СУБД должен поддерживать транзакции (не любой поддерживает!), а если он их поддерживает — можно их и через mysql_query точно так же инициировать, выполнять какие-то запросы, и завершать.


                                                    Также есть такой момент, что mysqli умеет работать с хранимыми процедурами. В принципе, я понимаю, что имеется в виду — чтобы сразу иметь возможность получать результат в переменную. Но мне на практике хватало создать хранимую процедуру через phpMyAdmin, вызвать её в нужных местах в самих SQL-запросах, и получить уже готовый результат. То есть это тоже как бы не то, без чего нельзя жить :)

                                                      +1
                                                      Вообще, рекомендую ознакомиться с PHP: The Right Way.
                                                        –1

                                                        Спасибо, интересный сайт. Но там опять про 7.1, прямо начиная с главной :) Нет у вас каких-нибудь Best Practices под PHP 5.3-5.4?


                                                        Но всё равно почитаю. Интересно же, что рекомендуют в качестве советов и правил хорошего стиля.

                                                          +2
                                                          Большинство описанных практик подходит и для >=5.3, только зачем использовать 5.*, когда есть 7.1?
                                                            –3

                                                            Не люблю, когда меня к чему-то принуждает разработчик платформы. И только. Так ничего против семёрки не имею.


                                                            Это знаете, как с NetBeans. Вот стоит у меня версия 6.8, всем она нравится… Но нет под неё расширений. Ни для CodeIgniter (вообще), ни под новый клиент SVN (а старый не поддерживается серверами, небезопасным считается). И приходится либо ставить что-то новее, либо без поддержки SVN сидеть. А казалось бы, что стоило авторам разрешить установку новой версии модуля (всё равно API небось не поменялся существенно) на старую версию IDE.

                                                              +1
                                                              Попробуйте PhpStorm (если по EAP — бесплатно). Попробуйте GIT. Если хотите SVN — был когда-то инструмент TortoiseSVN — не знаю как он сейчас поживает, либо юзайте CLI для SVN.
                                                                –2

                                                                У меня стоит TortoiseSVN, к счастью, версия 1.7 на моей ОС поддерживается ещё. Но хочется-то сразу из IDE чтобы было)) К хорошему быстро привыкаешь. Хотя конечно это всё ерунда, можно без проблем работать и в 7.х, или какие уже там, может и восьмые.


                                                                Просто меня в момент выхода 7.0 добили две вещи: огромное количество варнингов к моему Java коду, которые я понятия не имел, как исправить, чтобы их стало хотя бы на треть меньше, и то, что они полностью убили встроенный Javadoc. Все имена переменных в выпадающих элементах справки поменялись на i1, i2, i3… Помучился неделю и снёс. Возможно, к версии так 7.4 это и исправили. Но вообще-то такое сразу в идеале должно работать. Не RC ведь ставил, релиз нормальный.

                                                                  +3
                                                                  Если IDE кидает вам варнинги — обычно это говорит о том, что у вас что-то не то с кодом. Лучше бы вам всё же попытаться разобраться с проблемными местами.
                                                                    –1

                                                                    Ну когда их было в прошлой версии 0, а стало over 80 штук (на файл, где около 1500 строк кода) — это не нормально… И я честно пытался рефакторить код. Избавился от силы штук от 4-5.


                                                                    Тем более, это не варнинг в стиле "всё плохо, красная иконка", это предупреждения о нарушении некоего стайлгайда в области композиции классов. И они там были буквально на каждый чих.


                                                                    Код не был кстати настолько ужасен, это была курсовая. Будь там всё плохо — мне бы препод раньше вставил за это :)

                                                      –1

                                                      Насчёт движков — InnoDB поддерживает, MyISAM, вроде как, нет (раньше точно не умел).

                                                  +1
                                                  все минусующие самостоятельно за вечер написали бы более грамотную реализацию

                                                  Штука в том, что писать собственный механизм авторизации "за один вечер" в принципе не стоит. Гораздо правильнее использовать проверенные решения (например, входящие в состав используемого фреймворка) и не писать велосипеды.

                                                    +3
                                                    И я не очень уверен, что все минусующие самостоятельно за вечер написали бы более грамотную реализацию (не глядя в сторонний код).

                                                    Я бы не написал. Но я бы и не взялся. Зачем, если уже есть работающие готовые решения?

                                          +4

                                          Есть ощущение что статья опоздала лет на 10. MySQL PDO уже давно пора освоить. Я это к тому что mysql_result() в php7 работать не будет.

                                            –7
                                            Да, не будет. А зачем именно семёрка? Я до сих пор на всех серверах благополучно 5.3 использую.
                                            Есть ещё правда mysqli, но лично мне с этим интерфейсом менее удобно работать. Хотя говорят, он лучше. Возможно, дело привычки просто.
                                              +6
                                              Я до сих пор на всех серверах благополучно 5.3 использую.
                                              Сегодня можно благополучно пользоваться бричками, как транспортом, но почему-то людям больше нравятся автомобили.
                                                –4
                                                А кроме шуток? Что за редкий функционал такой, ради которого стоит менять версию? Не, ну ладно там 5.2, там со сборкой мусора похуже, с производительностью, md5 хэш короче намного (по дефолту 16 символов вроде). Но 5.3 чем не вариант?
                                                  +4
                                                  Достаточно посмотреть руководство по миграции и, например, статьи на хабре и других ресурсах, бенчмарки (1, 2, тысячи их), чтобы пришла уверенность, что обновиться стоит.
                                                    –1

                                                    Спасибо, обязательно почитаю. Люблю статьи в таком формате.


                                                    Насчёт бенчмарков — вы уверены, что эти цифры получены не только за счёт оптимизаций в ООП и скалярного тайпхинтинга? Просто не очень верится, что всё остальное можно было ускорить, а не сделать медленнее, тем более, что внутренней кодировкой вроде как стал двухбайтовый юникод (а раньше однобайтовая была). Хотя возможно, это ещё с версии 5.6, я не помню, увы...


                                                    И была даже статья на Хабре про то, что "PHP6 не будет", там писали, что у авторов возникли огромные проблемы со скоростью при попытке перевести все строковые функции на работу с двухбайтовой кодировкой. В итоге оставили всё как есть, а чуть оптимизированную версию выпустили как 5.5.

                                                      0
                                                      Тайпхинтинг, кстати, даже замедляет работу, а не ускоряет её. Насколько я понимаю, его ввели скорее для удобства разработки и отладки. О том, какие улучшения были сделаны, есть статьи, слайды и видео, в котором Дмитрий Стогов рассказывает подробно.
                                                        0

                                                        Тайпхинтинг, ИМХО, должен ускорять процесс. Потому что он позволяет заранее рассчитать необходимые объёмы памяти под данные, и избавиться от кучи динамических проверок (которые неизбежны, когда переменная часто меняет тип). Опять же, где-то читал в авторитетном источнике, что это даёт большой прирост в скорости :)

                                                          +1
                                                          На SO есть довольно развёрнутый ответ.
                                                          tl;dr:
                                                          Today, the use of scalar and strict types in PHP7 does not enhance performance.
                                                            0
                                                            Because scalar type hints guarantee that a passed argument will be of a certain type within a function body (at least initially), this could be used in the Zend Engine for optimisations. For example, if a function takes two float-hinted arguments and does arithmetic with them, there is no need for the arithmetic operators to check the types of their operands.

                                                            In previous version of php there was no way to know what kind of parameter could be passed to a function, which makes really hard to have JIT compilation approach to achieve superior performance, like facebook's HHVM do.

                                                            @ircmaxell in his blog mentions the possibility of bringing all this to the next level with native compilation, which would be even better than JIT.

                                                            Последний абзац особенно здесь интересен. Если сделать компиляцию в нативный код (в strict mode-то кто мешает, хотя бы на уровне отдельных функций), то будет очень быстро. То есть как раз речь о том, чтобы скомпилировать один раз, и использовать постоянно.

                                                              0
                                                              Над JIT сейчас Дмитрий Стогов работает, емнип. Это будет, скорее всего, в восьмой версии. У нас речь о седьмой.
                                                        0

                                                        Как минимум со времён 5.3 оптимизировали работу с массивами, если не трогать ООП.

                                                          0
                                                          В итоге оставили всё как есть, а чуть оптимизированную версию выпустили как 5.5.

                                                          В этом отношении и в 7 оставили всё как есть и пока планов по изменению не будет.


                                                          А вообще проект на Symfony 1 с минимальными правками самого фреймворка на 7.0 стал показывать процентов на 30 меньшее время генерации ответа по сложным запросам и процентов на 70 меньшее потребление памяти по сравнению с 5.3.

                                                            –2

                                                            Так вы не сравнивайте Symfony (один из самых тяжёлых фреймворков) с легковесными проектами, где PHP только выборку из БД делает да результаты в виде JSON возвращает (ну максимум — какой-то HTML генерирует для выдачи в браузер). Там не так всё медленно, чтобы видеть прирост, мне кажется. Про массивы выше уже мне написали — но это только на очень большом числе итераций можно заметить, на малых объёмах сильно роли не сыграет.

                                                          –1

                                                          На самом деле, на очень маленьких проектах, и если хостинг не очень слабый, разницы можно не ощутить. У меня была даже совсем странная история, когда на простом веб-приложении (в рамках одного веб-хостинга с возможностью переключать версии) 5.3 работал быстрее чем 5.4, а 5.2 ещё быстрее, чем 5.3. И в целом, это может даже быть объяснимо: меньше функций, меньше синтаксических возможностей — меньше потребление RAM, где-то быстрее интерпретация. Хотя может, я и не прав. Трудно сказать.


                                                          Между 5.4 и 5.6 я тоже разницу ощущаю с трудом (хотя 5.6 вроде как побыстрее, но может, это эффект плацебо в действии такой).

                                                      +5
                                                      Я до сих пор на всех серверах благополучно 5.3 использую.

                                                      Вы это серьёзно? Статья по безопасности с целевой версией языка, поддержка которой полностью, включая закрытие уязвимостей, прекращена 2,5 года назад? Даже для 5.6 активная поддержка прекращена уже, только уязвимости будут закрывать ещё какое-то время.

                                                        –2

                                                        Конечно, серьёзно. Статья не по безопасности вообще, а с идеей, как немного улучшить стандартную базовую авторизацию, которую предлагают в простых учебниках начинающим.


                                                        Какая разница, какая версия? Если использовать общий и простой стиль написания кода, то код одинаково будет работать на любой версии (и везде без ошибок и предупреждений). Ну кроме расширения mysql, тут да, проблема.

                                                        0
                                                        А зачем вы тогда вообще пишите свои поделки на php? Затем и 7ка, что пора себя переучивать пользоваться composer, разобраться в неймспейсинге, psr и для авторизации/логина на сайте использовать готовые, безопасные приемы и рабочие проекты людей. Дело тут не в скорости работы интерпретатора языка, сколько в особенностях самого языка. Отступать на 2 шага назад каждый раз и не пробовать «новые» аспекты — это от слова худо — программист.
                                                          –4

                                                          А что такое composer и зачем он вообще?)


                                                          Это не поделки, а вполне реально работающие проекты, между прочим. Этот модуль довольно простой, но даже в нём была применена пара оригинальных фишек (пароль в открытом виде не хранится нигде, файл security инклюдится во все разделы как второй механизм проверки в придачу к обычной проверке $_SESSION['user_id']). У меня есть разработки существенно сложнее, естественно. Просто решил поделиться вот этой, подумал, кому-то будет интересно… Может, я ошибся, и это тривиально для всех.


                                                          готовые, безопасные приемы

                                                          В чём они безопаснее? Использование готового — обычно отупляет и отучает думать и писать код самостоятельно. А то да, встречал уже одного товарища, который библиотеку для авторизации на гитхабе нагуглил, вместо того, чтобы написать самому за пару часов.


                                                          и не пробовать «новые» аспекты

                                                          Не, попробовать-то можно, ради интереса. Только не надо всех обращать в свою религию, и убеждать, что эти аспекты жизненно важны и необходимы)

                                                            0
                                                            Инклюдить в каждом файле — вот это тупость.
                                                              0

                                                              Извините, почему же? А импорт пакетов в Java в начале файла класса — не тупость? А объявление неймспейса в C++? Не будьте так категоричны. Это всего одна строка, а файлов, куда надо её добавить (и больше не убирать) — штук 5-6. Прямо так сложно, Боже мой.

                                                              • UFO just landed and posted this here
                                                                  0

                                                                  Не забуду, если таких мест всего 2-3 на весь проект(в каждом кабинете, грубо говоря). Кроме того, при создании нового проекта обычно весь этот код банально копируется из старого. Тут разве что если стереть случайно. Но в этом плане с чем угодно можно напортачить, если думать о постороннем :)

                                                                  0
                                                                  А вы почитайте чем инклюд отличается от импорта. Может тогда дойдет
                                                                    –1

                                                                    Абсолютно ничем.
                                                                    Если вы про многократный инклюд одного и того же — require_once() есть на этот случай. Ну и при грамотной архитектуре все инклюды идут в главном модуле, а не где попадя.

                                                                      +1
                                                                      Абсолютно ничем.

                                                                      То есть тот малозначительный факт, что одно выполняет код, а другое — нет, вас не смущает?

                                                                        0

                                                                        Иногда такое выполнение бывает очень удобно. Смотрите это как на вызов внешней процедуры с глобальными параметрами.


                                                                        Вот нужно мне кусок шаблона вставить (календарь вывести или виджет какой-то). Что проще всего для этого использовать? Конечно, require или include. И уже там писать макароны, а не засорять основной файл-"каркас".

                                                                          0
                                                                          Иногда такое выполнение бывает очень удобно.

                                                                          Никто и не спорит с тем, что удобно. Спорят с тем, что include и import — разные вещи.


                                                                          Смотрите это как на вызов внешней процедуры с глобальными параметрами.

                                                                          Ну то есть как на абсолютное зло?


                                                                          Вот нужно мне кусок шаблона вставить (календарь вывести или виджет какой-то). Что проще всего для этого использовать? Конечно, require или include.

                                                                          Проще — возможно (вам). Правильнее? Далеко не факт, я всегда предпочту явный вызов кода.


                                                                          Собственно, с этого же все и начиналось — правильно ли подключать проверку безопасности через include. Нет, неправильно — потому что можно забыть сделать include и кусок останется незащищенным. Правильно ли подключать через import и вызов кода? Да тоже не очень, потому что можно забыть вызов.


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

                                                                        0

                                                                        При грамотной архитектуре (да и вообще в любом проекте в 2017ом году) инклуд только один на весь проект — require '... autoload.php'; — остальное декларативные методы ссылок на нужные вендорные (и не только) либы.

                                                                          0

                                                                          Автозагрузку функций пока ещё не сделали.

                                                                            +1

                                                                            И что? Вы документацию композера пропустили, где для этого есть специально прописанная секция files? ;)


                                                                            Прошу заметить, что в проекте как был, так и остаётся один единственный require. Моих слов это не отменяет.

                                                                            0

                                                                            Я где-то в документации читал, что использование автозагрузки через регистрацию функции-автозагрузчика может давать сильные тормоза по сравнению с её неиспользованием. Вы не могли бы прокомментировать как-то этот момент?


                                                                            И потом, вы сейчас говорите про проект, написанный в объектном стиле. Если это не так, зачем нам autoload?


                                                                            Просто я бы не согласился, что проект, не использующий ООП — сразу с порога проект с плохой архитектурой. Смотря как сделано...

                                                                              0
                                                                              Вы не могли бы прокомментировать как-то этот момент?

                                                                              Нет, десятитысячные доли секунд на виртуалках за 100 рублей\мес меня мало волнуют =)


                                                                              И потом, вы сейчас говорите про проект, написанный в объектном стиле. Если это не так, зачем нам autoload?

                                                                              А зачем писать как-то иначе и жрать кактусы? Есть инструмент — используйте, если инструмент не достаточно удобен, значит он не для этого.


                                                                              Просто я бы не согласился, что проект, не использующий ООП — сразу с порога проект с плохой архитектурой. Смотря как сделано...

                                                                              Я бы посмотрел на проекты с более чем 20ю метрами исходного кода в процедурном стиле, а ещё такой грамотный по архитектуре… Примеров не найдёте? Ну таких, чтобы сразу в помойку не выкидывать, а чуть-чуть повосхищаться дерзостью автора.


                                                                              ООП, хоть и критикуемый, но по праву заслужил свои позиции. Действительно крупные проекты, ну или чуть круче лендингов при других подходах слабореализуемы.

                                                                                0

                                                                                Почему кактусы? Для меня, например, объектный стиль менее удобен. Существенно причём.


                                                                                А не подскажете, где такие дешёвые виртуалки? Я вроде искал варианты, и везде намного дороже всё...


                                                                                Действительно крупные проекты, ну или чуть круче лендингов при других подходах слабореализуемы.

                                                                                Ну 20 метров — это очень много. Таких у меня, я думаю, нет. Но и круче лендингов я делал много разных вещей, и процедурный стиль там более чем уместен. Более того, если оформить всё чуть опрятнее и задействовать разделение на файлы и шаблонизацию более активно, то и в команде над таким кодом работать совсем не так болезненно будет, как вы думаете.

                                                                                  0
                                                                                  реквайры\инклуды, да? но это же банально неудобно
                                                                                    0

                                                                                    Пока их совсем мало — довольно удобно.


                                                                                    Я понимаю, что выглядит обычно хуже (хотя бы потому, что глобальная область видимости — это фу), но зато сразу снимается ответственность за написание красивой архитектуры (которая автоматом появляется, когда создаёшь модель классов).


                                                                                    Объектный код — к нему ведь при оценке другие программисты придираются не меньше, даже больше часто :)

                                                                                      0
                                                                                      Пока их совсем мало — довольно удобно.


                                                                                      А когда много? Это просто выбрось и пиши заново.

                                                                                      зы. Для себя взял за правило небольшие проектики стартовать на чемто типа silex/slim. По началу можно прямо в index.php фигачить в колбеках роутов. Когда становится их много просто віносишь в классы-екшены. По мере необходимости инкапсулируешь усложнившуюся логику в сервисы, инжектишь при помощи контейнера куда надо.
                                                                                        0

                                                                                        Примерно представляю, про что речь...) Но index.php с кучей роутов — это тоже та ещё жесть.


                                                                                        Я раньше делал архитектуру двух типов, на самом деле (оба страшно выглядели, но оно более-менее работало). Первый вариант — это куча макарон (шаблон и пара блоков с бизнес-логикой в одном файле) на каждую крупную страницу системы (например, кабинет администратора, чтобы уровень детализации был понятен). При этом данные при загрузке получаются синхронно, чтобы юзер не ждал, параллельно реализуются точки отдачи данных в JSON в виде отдельных файлов — для AJAX.


                                                                                        Второй подход — как первый, но в этом случае синхронно ничего не загружается, чтобы избежать макарон, всё загружается только через JSON из JavaScript. Выглядит красивее, по ощущениям от использования приложения — похуже.


                                                                                        В последнем проекте применил вообще немного сумбурный и слегка нелогичный метод с помещением скриптов выборки данных в отдельные файлы. При этом эти файлы используются и при получении данных аяксом, и через инклюды (в файлах есть ветвления). Формат отдачи и сам набор данных, например, все ли строки отдавать или с фильтрацией — определяется через переменную, то есть перед инклюдом, грубо говоря, ставятся некоторые флаги прямо в $_GET массив. Звучит не очень, но это позволило вынести кучу кода из основного файла, и слегка уменьшить число файлов-обработчиков (не в два раза, но всё-таки).

                                                                        0
                                                                        А импорт пакетов в Java в начале файла класса — не тупость? А объявление неймспейса в C++?

                                                                        Там такую необходимость даже специально проигнорировать не получится — компилятор/линковщик напомнит.
                                                                      0
                                                                      А то да, встречал уже одного товарища, который библиотеку для авторизации на гитхабе нагуглил, вместо того, чтобы написать самому за пару часов

                                                                      Ну, вот вы написали, а толку? Дыра на дыре сидит и дырой погоняет. Причём вы ещё и принципиально отказываетесь понимать что вам говорят. Ваш товарищ поступил гораздо мудрее.

                                                                      • UFO just landed and posted this here
                                                                +4
                                                                Тенденция прямо: людям с фамилией Попов в IT не всегда везет :)
                                                                (это добрая шутка если что)
                                                                  –2
                                                                  Зато есть очень талантливый мой полный тёзка, который неплохие видеоуроки по вебдизайну выпускает. Кто-то из моих знакомых очень хвалил его :)

                                                                  А тот Попов — ну там да, что поделать. Бывает)
                                                                    +1
                                                                    Ну, Никита Попов хорош.
                                                                    +3
                                                                    Возьмите и разберитесь в любом из данных проектов slim-basic-auth, slim-auth, slim-jwt-auth, slim-token-authentication. Даже на примере фреймворка Slim, вы взглянете на свой кусок кода как на нечто… неприемлемое для современного Веб.
                                                                      –3

                                                                      К чему в вашем предложении слово "современного"? Как будто понятие безопасности и устойчивости к разным угрозам зависит от времени.


                                                                      Код посмотрю, спасибо. Пока из описания понял, что это некая надстройка над модулями Zend… В котором уже и так есть что-то для аутентификации.

                                                                        0
                                                                        На одном из западных форумом, посвященных безопасности в Веб, сказано очень лаконично и просто «не пытайтесь создавать безопасность своими руками, используйте рекомендованные решения, созданные специалистами по безопасности». Я использовал слово «современного» в контексте даже информации о рекомендациях не использовать md5 для кодирования парольной информации, а использовать более стойкие и новые криптографические методы.
                                                                          –2

                                                                          Я не сам это придумал. Функция md5 используется, например, в CMS Joomla 1.5 для хранения хэшей паролей (собственно, сам формат хранения и идею делать равными по длине соль и хэш я взял оттуда в своё время). Более того, в другой CMS (не очень популярной, типа Street CMS) я видел ещё менее стойкое шифрование — там очень короткие на вид были строки.

                                                                            0
                                                                            То что там испоьзуется — не значит что это правильно…

                                                                            Выдержка с php.com:
                                                                            «Why are common hashing functions such as md5() and sha1() unsuitable for passwords?
                                                                            Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to „brute force“ the output of these algorithms, in order to determine the original input.

                                                                            Because of how quickly a modern computer can „reverse“ these hashing algorithms, many security professionals strongly suggest against their use for password hashing.»
                                                                              –2

                                                                              Я читал опять же статьи на эту тему, — какой нужен объём диска, сколько памяти, и сколько процессорного времени для подбора хэшей MD5. Выходило довольно много. Под 300-450 Gb радужных таблиц на диске (тогда как 500-гигабайтный USB жёсткий диск стоил довольно прилично, хоть и не заоблачно, и не каждый мог позволить его пустить на такое даже при большом желании), плюс существенное время, исчисляемое сутками. И то там рассматривалось вскрытие хэшей, полученных без соли, и вроде даже частично содержащих слова.


                                                                              Так что мне кажется, авторы слегка перестраховываются (как и все специалисты по криптографии), играя на опережение, и предупреждая всех заранее, чтобы потом всех не застало врасплох.

                                                                                0

                                                                                <cap-mode>Ну, 450 Гб довольно мало.
                                                                                За несколько тысяч рублей можно HDD на 2000 Гб купить.</cap-mode>

                                                                                  –1

                                                                                  Ну, в 2009-ом это стоило несколько дороже (когда я ту статью смотрел). Хотя тоже было конечно же вполне реально :)
                                                                                  Но вот году ещё в 2008-ом в самом начале, когда родители этот Seagate покупали — там полутерабайтные внешние накопители стоили прилично. Тысяч 8-10 минимум.


                                                                                  То есть это надо было выкинуть 8-9к, чтобы с некоторой вероятностью что-то подобрать (а скорее, ничего не подобрать). Плюс скорость доступа у этих винтов была сильно не очень.

                                                                              +3
                                                                              Joomla — это явно не тот проект, с которого нужно брать пример.
                                                                                –2

                                                                                Да хорошая же система) Я между прочим частично читал её исходники. Красивый там код.

                                                                                  +1
                                                                                  Не-не-не, вы не на тех проектах учитесь. Лучше смотрите исходники симфони, его компонентов.
                                                                                    –1

                                                                                    Хорошо, я учту)

                                                                                  0

                                                                                  А аргументировать как-то это слабо? :)
                                                                                  Особенно учитывая, что там всё в лучших традициях ООП сделано.

                                                                                    0
                                                                                    Не хочу тратить на это время.
                                                                                    там всё в лучших традициях ООП сделано
                                                                                    Смешно.
                                                                                      0

                                                                                      А что смешного, если это так? Есть CMS-ки, сделанные и в процедурном стиле как бы.
                                                                                      Не хотите — ваше право, но я так понял, у вас просто весомых аргументов нет. А это как бы один из лидеров на рынке бесплатных CMS. Наравне с Wordpress и Drupal

                                                                                        +1
                                                                                        Вы шутите?!!! На моей памяти — джумла самая дырявая, не говоря о коде (про это я писал выше).
                                                                                          –1

                                                                                          Да, ладно, по сравнению с вордпрессом и битриксом — на джумлу можно молиться =)

                                                                                            +1
                                                                                            Не согласен, но спорить не буду)
                                                                            0

                                                                            Я посмотрел код по первой ссылке (по первым двум, у вас там одинаковая вставилась). Лаконично, абстрактно, но не очень понятно, что же там на самом деле происходит. Это очень высокоуровневый код, он сильно на код Zend опирается. Вы и код Zend мне почитать предлагаете?)

                                                                              0
                                                                              Документацию не нужно читать, в первом случае используются компоненты из билиотеки Zend, адаптированы под использование в фреймворке Slim. Дважды вставил верно slim-basic-auth. Там нет никаких прямых обращений к БД — эта практика сама по себе небезопасна. Вам выше уже указали на места, которые могут быть подвергнуты sql-инъекциям и вещам пострашнее.
                                                                                0

                                                                                Но БД существенно производительнее файловой системы (попробуйте запустить 2-3 скрипта на longpoll от одного юзера и попытаться в цикле подёргать сессию, будет не очень здорово). Насчёт инъекций — есть функции экранирования, есть PDO, как сказали выше, есть здравый смысл наконец. Не вижу никаких причин её не использовать. Более того, можно создать свой обработчик PHP сессий, который будет сохранять их в БД, а не в файлах, в языке предусмотрели даже такую возможность. Вот здесь об этом упоминается: http://www.php.su/articles/?cat=protocols&page=009

                                                                                  0
                                                                                  Сессии вы можете хранить где угодно: хоть в файлах, хоть в in-memory, хоть в MySQL — где угодно. Удобно, кстати, добавить уровень абстракции «хранилище сессии», механизму аутентификации должно быть пофиг где эта сессия хранится. Вас критикуют за то, что вы небезопасно реализовали.
                                                                                    0

                                                                                    Вот мне правда интересно узнать, как реализовать безопасно, я же не троллинга ради спрашиваю.
                                                                                    Если в БД хранить можно — то из недостатков остаётся только низкий уровень абстракции и привязка к деталям реализации. Код можно сделать красивее и разнести его на несколько уровней абстракции, хотя его станет побольше. Но это к вопросу о красивой архитектуре, а не о безопасности :)

                                                                                      0
                                                                                      А про реализацию в интернете достаточно материала. Читайте-изучайте.
                                                                                        0

                                                                                        Нет, я имею в виду, что в текущем варианте не ок. Ну код там не красивый в самом скрипте аутентификации — это понятно, я как бы не старался его делать хорошим. А с остальным всё ведь хорошо?


                                                                                        Опять же, хочу напомнить, что общую идею хранения идентификационных данных в сессии придумал не я. Это в каждой первой статье делать предлагают. Да и в CMS по-моему так же сделано, например в той же Joomla, откуда я брал формат хранения паролей.


                                                                                        Вообще способов-то не так много: нам нужен клиентский контейнер, транспорт и серверный контейнер. Клиентский контейнер — очевидно, cookie (их проще всего выставить с сервера).


                                                                                        Транспорты рассматриваются по ссылке в статье, которую я приводил в комментарии выше. Обычно, опять же, используют cookies, поскольку они очень редко отключены у пользователей, и при этом не нужно городить параметров в адресной строке и виртуальных каталогов.


                                                                                        Остаётся серверный контейнер — по дефолту для сессий в PHP это файлы. Я, по сути, реализовал свой независимый контейнер хранения (можно считать это велосипедом, конечно), который работает совместно со стандартным, основан не на файлах а на MySQL, и хранит немного другие вещи.


                                                                                        При этом кука с хэшом ставится сервером при аутентификации (и шифруется им же), а затем передаётся клиентом с каждым запросом. И специальным модулем проверяется на корректность (как признак валидности клиента, она ведь получена из пароля). Вроде всё нормально сделано.

                                                                                          +2
                                                                                          На самом деле, всё ужасно от слова «совсем».
                                                                                          1. md5. даже не sha1. при том, что давным-давно практически во всех уголках инета рекомендуются спец.функции. Раньше был crypt, сейчас очень рекомендуется использовать password_*.
                                                                                          2. mysql. ну про это выше неоднократно написали.
                                                                                          3. sql-inj. тоже написали.
                                                                                          4. хранение пароля в сесии (не важно, php- или своей). Что-за бред? Почему в базе храним хешированный пароль, а в сесии нет? Храним хешированный с другой солью + подпись для проверки целостности данных. Эти 2 простых приема дадут больше пользы, чем весь код в посте.
                                                                                          5. Привязка к ip — это жесть. Вы часто приводите в пример vk, но я уверен, что там это реализовано иначе — проверям, сменилась-ли страна/регион/город с момента последнего обращения, а не смену ip. Не должна аутентификация быть привязана к чему-то, кроме самого пользователя.
                                                                                          6. Никогда(!) и никому(!) не говорите ничего про джумлу. Хуже кода, лично я, не видел ни разу.

                                                                                          И да, хотите сделать что-то правильно — хотя-бы(!) изучите то, что сделали и проверили в работе другие люди.

                                                                                          P.S.: отдельная жесть — php 5.3, svn. Тут даже не знаю что сказать…
                                                                                            0
                                                                                            1. Не знаю, UnitPay (платёжка, с которой мы год работали) только полгода как от md5 в пользу sha1 отказался. Там это используется для получения контрольной подписи. Принципиально есть какие-то аргументы, почему md5 не есть гуд? Ещё раз, я читал анализ, за вменяемые сроки там ничего не получить. А то, что получить — обычно это то, что УЖЕ когда-то было скомпрометировано, и теперь просто мы детектируем, что это тот самый хэш, или очень близкий. Тем более, не используя GPU, и на хэшах, где использовалась соль (любая).


                                                                                            2. Никто так и не объяснил, что не так с mysql. Один человек жаловался на особенность mysql_connect на Тостере, что функция не создаёт ему новое соединение, если не передан четвёртый параметр — но это называется "неумение читать документацию", библиотека тут ни при чём. То, что в неё давно не пилят какие-то новые фичи — не проблемы разработчика, коль скоро эти фичи ему не нужны.


                                                                                            3. С этим я согласился и исправил :)


                                                                                            4. С чего вы взяли что пароль(!) хранится в сессии? Такое ощущение, что вы вообще не читали статью, либо читали её через абзац. В сессии хранится хэш. Причём другой, не тот, что в БД. Как вы и предложили, ровно таак и работает это.


                                                                                            5. Частично согласен, что это может создавать неудобства, но это не доставляет сильных проблем обычному юзеру, поскольку автоматический перелогин происходит мгновенно. Да, это незачем, возможно, это глупость… Впрочем, не глупость. Это позволяет записывать в лог каждое изменение IP пользователя. Может я как администратор хочу знать, с каких провайдеров и как долго человек сидел на моём ресурсе? :)


                                                                                            6. Вы зря настроены так против Joomla. Там прекрасный код в стиле ООП. И судя по тому, что я слышал о Wordpress (и частично видел сам) Joomla намного лучше. Это просто земля и небо. Да и API для расширений там очень и очень вменяемое. Смотрел видеоуроки даже по написание расширений под неё.

                                                                                            P. S. К SVN какие претензии? :)

                                                                                              +1
                                                                                              Никто так и не объяснил, что не так с mysql

                                                                                              Если того, что уже практически не поддерживается, мало, то, навскидку, ничего не знает о транзакциях и подготовленных выражениях.

                                                                                                0
                                                                                                1. Видимо мы разные вещи читаем. Пост от 2013-го года (4 года прошло!!) — 2,2 млрд. хешей в секунду. Не говоря уже о том, что сам md5 взламывают с 2009-го года. Добавим сюда коллизии, готовые rainbow tables и… Не могу найти ни одной причины, чтобы юзать md5 в 2017-м году. Особенно с учетом того, что есть готовые функции, которые делают эту работу намного проще, удобнее и надежнее. За UnitPay спасибо — не буду юзать, раз все так плохо.

                                                                                                2. Ну как объяснить… Ок, давайте попробую так: пилите-пилите проект, разросся он до нескольких гигабайт и тут решили переехать на новую версию php (7-я реально сильно быстрее 5.х). И? Начинаются костыли и рвание волос в одном месте, т.к. использование различается кардинально. Поверьте, не на ровном месте это говорю — проходил на личном опыте, когда надо было обновить проект с историей более 10 лет. Это только одна из причин, их можно легко набрать пару десятков.

                                                                                                4. видимо не внимательно прочел, прошу прощения.

                                                                                                5. Эмм…

                                                                                                >Это позволяет записывать в лог каждое изменение IP пользователя.

                                                                                                Как это связано с аутентификацией? Логи — это совсем другое. Логируйте смену ip, в чем проблема-то? Но ip точно не должно быть частью авторизации/аутентификации.

                                                                                                6. Ммм… Давно не трогал, решил посмотреть — может что изменилось… Ан нет… god-объект Application, по всему коду синглтоны, за такое руки оторвал-бы, тут «на всякий случай»? И это я пару файлов наугад ткнул. По поводу вордпресса — я вроде не предлагал учится на его коде).

                                                                                                >К SVN какие претензии? :)

                                                                                                Их слишком много) От тормозной работы (т.к. только diff, а не полная копия), до stash и удобства разруливания конфликтов.
                                                                                                • UFO just landed and posted this here
                                                                                                    0
                                                                                                    Хм… А с чем именно не согласны? С тем, что svn работает медленее? Или с тем, что разруливание конфликтов в snv связан с трагедией, когда идет переименование директорий?

                                                                                                    А насчет ссылки… Обсуждалось-же уже на хабре. Как говорится — «ложь и провокация»)))
                                                                                                    • UFO just landed and posted this here
                                                                                                        0
                                                                                                        Хм… Ну я и не заманиваю. На вкус и цвет…
                                                                                                        А что касается скорости/юзабельности — лично я на свн уже ни ногой никогда. Использовал лет 5-7 (в основном из-за возможности lock/unlock + исторически).

                                                                                                        >Вы просто не умеете его готовить.

                                                                                                        Возможно, даже не спорю… Но отвечу в вашем стиле: «Не заманите вы меня на ваш хромой svn, не пытайтесь.»)
                                                                                                        • UFO just landed and posted this here
                                                                                                            0
                                                                                                            А можете чуть подробнее рассказать, что именно вызывает «тошноту»? Кроме эмоциональной составляющей. В чем svn удобнее?
                                                                                                            • UFO just landed and posted this here
                                                                                                                0
                                                                                                                git распредленній и синкает только то, что вы решили сами засинкать. Локально вы можете держать 100500 веток, мерджить, черипикать, ребайзить что угодно и когда посчитаете что код готов — запушить одну финальную бранчу и оформить по ней пулл-реквест. Даже если вам влом разбираться, то освоить пулл и пуш может даже первокурсник.
                                                                                                                • UFO just landed and posted this here
                                                                                                                  +1
                                                                                                                  Ну хоть понятно стало, что вы просто не хотите меняться…

                                                                                                                  Если коммитишь в git, он делает непонятно что, в чём без чтения документации каждый раз не разобраться


                                                                                                                  Если коммитишь в гит — код именно коммитится. В локальную репу. И это огромный плюс. Позволяет разделять задачу на мелкие подзадачи и выполнять их отдельными коммитами, а в ветку пушится общий результат.

                                                                                                                  после чего надо выдавать ещё какие-то непонятные команды, чтобы код таки попал в сетевой репозиторий


                                                                                                                  Это git push не понятный?)) Ну оок…

                                                                                                                  При работе с проектом, где используется git, у меня очень много времени уходит на борьбу с ним.


                                                                                                                  Сорри, но в это я не верю. От слова совсем. Скажем так — если вы действительно используете гит, то либо юзаете 5-6 комманд (которые запоминаются через минуты 2-3), либо используете возможности ide/gui/etc. В любом случае, получается точно не сложнее чем с svn. А вот разруливать конфликты в гите значительно удобнее.

                                                                                                                  Например, на написание скриптов, которые делают с его помощью то, что с SVN делается одной командой.


                                                                                                                  А можно пример подобного? Мне реально интересно. Не смог вспомнить ни одного случая, когда svn был-бы проще и удобнее. Мне вот часто необходимо слить несколько коммитов в 1, объединить несколько веток в одну, поправить часть кода и запушить в новую ветку, не трогая мастер. Такое проще в svn сделать?

                                                                                                                  Я не троллю, мне реально интересно. Последний раз, когда трогал svn, последний был версии 1.5 или 1.6, уже точно и не помню. Тогда использование его было целой трагедией. Сейчас многое поменялось?
                                                                                                                  • UFO just landed and posted this here
                                                                                                                      0
                                                                                                                      Как отключить локальную репу в git?


                                                                                                                      А как в svn сделать локальные репы?

                                                                                                                      Я пишу код и хочу, чтобы он, чёрт побери, попал в сетевую репу в нужную ветку.


                                                                                                                      Круто. git commit & git push. В чем проблема? А как сделать в svn, чтобы в сетевую репу не попали куча разных коммитов, а попал только один, финальный?

                                                                                                                      В SVN это делается одной командой.


                                                                                                                      Верно. Потому (только не злитесь) что svn ущербен. На большее, кроме как получить/отдать, он от рождения не способен. Да, в простых случаях этого хватает. Но не всем и не всегда.

                                                                                                                      Зачем сливать коммиты?


                                                                                                                      Чтобы в истории видеть 1 коммит = 1 задаче, но при этом в разработке дробить эту задачу на 100500 мелких и решать их отдельно разными коммитами.

                                                                                                                      Не пуше каком-то, я не понимаю что это такое и зачем это нужно.


                                                                                                                      Ну так вот она проблема, а не в гите ;). Ну серьезно.

                                                                                                                      Не вижу проблем в SVN при объединении веток или коммите в новую.


                                                                                                                      Я тоже в гите таких проблем не вижу. Но коммит, для меня, это локальное действие.

                                                                                                                      Я отправляю свой код в сетевой репозиторий, и это — коммит.


                                                                                                                      Да, в svn это «коммит», т.к., повторюсь, он ущербен от рождения. Как будет работать такой коммит в самолете, например? Мне вот необходимо разделение:

                                                                                                                      коммит — фиксирование изменений кода
                                                                                                                      пуш — обновление кода в ветке

                                                                                                                      И все сразу становится на свои места. А что такое коммит в svn? Только обновление кода. Теперь представим, что необходимо во время разработки переключаться между 3-мя ветками (пусть, для простоты понимания, мы работаем с микросервисами). Как в таком случае быть с svn? Удобно?)

                                                                                                                      Это вносит путаницу. И лично меня — бесит неимоверно.


                                                                                                                      Нет. Ни гит, ни svn путаницу не вносят — их вносите вы сами. Вас-же не бесит, что у велосипеда и мотоцикла по 2 колеса, но работают они иначе, да и пользуются ими совсем по разному? А чай вы из тарелки ложкой употребляете? Нет-же, верно? Так и тут — если нет желания, найдется 100500 причин (причем местами довольно смешных) чтобы только себя позлить.

                                                                                                                      Честно, как только svn научится работать с локальными изменениями, объединением/разделением коммитов (в том числе с возможностью удалить/отредактировать 3-й из 10-и коммит) — тогда я начну воспринимать эту детскую игрушку более-менее серьезно.

                                                                                                                      Но если вас устраивает svn — используйте. Повторюсь — на вкус и цвет… Мне вот hg совсем не подошел, а svn уже не достаточен — потому и git. Да, в гите тоже есть свои неудобства, свои кривоватости и прочее, но они как-то проще что-ли…
                                                                                                                      • UFO just landed and posted this here
                                                                                                                          0
                                                                                                                          Зачем мне две команды на одно действие? Глупость какая-то.

                                                                                                                          Это разные действия).
                                                                                                                          Вы хотите спрятать подробности разработки от сообщества? Не понимаю, зачем это надо. Мне лично нечего скрывать в своём коде.

                                                                                                                          Прятать? Вы о чем? Я не хочу, чтобы недоделанная задача повлияла на пару десятков других разработчиков. В svn это сложно.
                                                                                                                          Причина в том, что мне не нужны эти операции по отдельности, потому я не понимаю, зачем их разделили.

                                                                                                                          А многим нужны именно по отдельности. И желание появилось не на ровном месте.
                                                                                                                          Приведите пример, зачем это может быть нужно.

                                                                                                                          Я уже приводил выше: решение одной большой задачи итерационно, разбивая ее на множество мелких.
                                                                                                                          Зачем работать с 3 ветками одновременно? Создайте свою и работайте в ней, потом затащите изменения из неё в другие. Создаёте проблемы на пустом месте.

                                                                                                                          Можно я не буду на это отвечать?)))
                                                                                                                          Я теперь не могу работать над своим кодом в сообществах, используя SVN, понимаете?

                                                                                                                          И это хорошо! Чем меньше плохого инструмента в обращении — тем лучше.
                                                                                                                          Мне вот не нравится drupal, но это не означает что он плохой, верно? Хотя нет — для меня он ужасен.

                                                                                                                          А для меня извращенцы — это пользователи git

                                                                                                                          На вкус и цвет… Если-бы svn был удобен — с него не убегали бы. А с него бегут. Не только в git, но и в hg и в bazaar. Бегут именно по причине того, что svn не дает работать.

                                                                                                                          Думаю, на этом и закончим. Мне уже понятно, что у вас чисто эмоциональная неприязнь инструмента.
                                                                                                                          • UFO just landed and posted this here
                                                                                                                              –2

                                                                                                                              Между прочим, Хромиум использовал именно SVN раньше, в 2013-ом по крайней мере точно, когда я впервые выкачивал их исходники. Ну и мы в вузе использовали SVN с первого курса. Поэтому да, возможно во мне говорит привычка. Но я всё-таки за централизованный подход. Любая децентрализованная система — это обычно хаос. В SVN один репозиторий и много рабочих копий у разработчиков. В Git у каждого разработчика по репозиторию. Что за бред вообще?) И как это синхронизировать, чтобы твой репозиторий был постоянно актуален. Жесть же. И логически (при конфликтах), и по ресурсам на синхронизацию.

                                                                                                                                0
                                                                                                                                И как это синхронизировать, чтобы твой репозиторий был постоянно актуален.

                                                                                                                                Приблизительно так же, как синхронизируются локальные рабочие копии с центральным репозиторием.


                                                                                                                                А зачем мне постоянно актуальный репозиторий, кстати?


                                                                                                                                И логически (при конфликтах),

                                                                                                                                Конфликты — они между ветками обычно, а не между репозиториями, так что здесь нет никаких дополнительных накладных расходов.

                                                                                                                            0
                                                                                                                            Чтобы в истории видеть 1 коммит = 1 задаче, но при этом в разработке дробить эту задачу на 100500 мелких и решать их отдельно разными коммитами.

                                                                                                                            Что за маниакальное желание делать коммит каждого мелкого изменения? Вам кнопочки Save мало? Я уже молчу про то, что многие IDE поддерживают Local History для отката изменений.


                                                                                                                            Если же изменений много, и это целая подзадача — наверное, логично сделать обычный сетевой коммит, как он делается в SVN.


                                                                                                                            Да, в svn это «коммит», т.к., повторюсь, он ущербен от рождения. Как будет работать такой коммит в самолете, например?

                                                                                                                            А зачем вам делать коммит в самолёте? Достаточно сохраниться, а закоммитить всегда можно при приземлении. Вы придумываете проблемы там, где их нет)

                                                                                                                              0
                                                                                                                              Что за маниакальное желание делать коммит каждого мелкого изменения?

                                                                                                                              А почему нет? Это бывает удобно.


                                                                                                                              А зачем вам делать коммит в самолёте?

                                                                                                                              Чтобы видеть историю работы.

                                                                                                                                0

                                                                                                                                Бывает, но не всем. Давайте тогда остановимся на том, что это личные пристрастия каждого. И не будем никого оскорблять)


                                                                                                                                Кроме того, есть и аналоги, позволяющие видеть историю изменений, но при этом не держать локально целый репозиторий (в любой системе контроля версий). Простейший — это "вшитые" в IDE модули локальной истории, но я верю, что есть варианты ещё мощнее (но не такие мощные и универсальные, как тот же Git). Просто мне это было не нужно, не изучал вопрос.


                                                                                                                                P. S. И правда может быть удобно откатить мелкий фрагмент изменений, но на то, чтобы во время написания кода думать о том, где провести границы между этими фрагментами — уходят мыслительные ресурсы и время. Тут спорно, будет ли выигрыш. Я бы не заморачивался :)

                                                                                                                                  +2
                                                                                                                                  Бывает, но не всем. Давайте тогда остановимся на том, что это личные пристрастия каждого. И не будем никого оскорблять

                                                                                                                                  Это говорит человек, написавший слово "маниакальное"?


                                                                                                                                  Простейший — это "вшитые" в IDE модули локальной истории

                                                                                                                                  Для меня не работает.


                                                                                                                                  верю, что есть варианты ещё мощнее (но не такие мощные и универсальные, как тот же Git).

                                                                                                                                  … но зачем, если просто есть DVCS, которая делает и это, и контроль версий для совместной разработки? Зачем использовать два инструмента, когда есть один, который прекрасно справляется с задачей?


                                                                                                                                  И правда может быть удобно откатить мелкий фрагмент изменений, но на то, чтобы во время написания кода думать о том, где провести границы между этими фрагментами — уходят мыслительные ресурсы и время

                                                                                                                                  У кого-то уходят, у кого-то — нет. Я задачу заранее разбиваю на кванты обычно, потому что иначе она может выглядеть неподъемной. Сделал квант — сделай коммит.


                                                                                                                                  И это мы еще переключения не рассматриваем.

                                                                                                                                0
                                                                                                                                Что за маниакальное желание делать коммит каждого мелкого изменения?

                                                                                                                                Как минимум, это удобно для ревью. Ну и если используется что-то типа TDD, то даже это минимальное изменение не нарушает работу кода. Коммитить неработающий код — обычно зло. В процессе работы над новой фичей часто код становится неработающим, а потом становится работающим, пускай фича пока и н ереализована до конца. Имеет смысл фиксировать шаги когда код рабочий.

                                                                                                                          • UFO just landed and posted this here
                                                                                                                              0
                                                                                                                              вот это у вас подгорает.
                                                                                                                              • UFO just landed and posted this here
                                                                                                                                  0
                                                                                                                                  трольвальдс — тонкий тролль, да.

                                                                                                                                  Не нравится мне он, но в вашем случае проблема точно не в нем и не в троллинге ;)
                                                                                                                                    0
                                                                                                                                    Не работайте с гитом. Я вам разрешаю. Психологиеское здоровье важней денег.
                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                  0
                                                                                                                                  Странное решение проблем. Да еще и «несколько раз в день».
                                                                                                                                  Итак, если при коммите возникла какая-то очередная непонятная ошибка

                                                                                                                                  Например? Мне кажется — вы сейчас сильно лукавите. Если проблема в коммите — у вас проблема с настройками и/или правами. Если в пуше — значит у вас конфликт, который легко разруливается. А ваш «рецепт» похож на мазохизм, из серии «пусть мне будет плохо, но я так хочу»…
                                                                                                                                  • UFO just landed and posted this here
                                                                                                                                      0
                                                                                                                                      Я ничего не трогала, оно само!
                                                                                                                                      • UFO just landed and posted this here
                                                                                                                                          0
                                                                                                                                          Может стоит научится пользоваться молотком? Да, молотки бывают разные и для разных целей. А еще у них бывают разные ручки — одни удобнее, другие нет.
                                                                                                                                          Вот svn в качестве молотка отвратителен — сбитый боек, треснутая ручка, не работает когда не подключен к интернету, не работает, когда нужен сразу нескольким трудягам — один ручку забрал, другой боек и ни у одного не получается забить гвоздь.

                                                                                                                                          А когда им обоим говорят — вот, возьмите бесплатно каждый по новому молотку с удобной ручкой, говорят нет, у новых молотков ручка слишком удобная, не привычно, тяжело себе по пальцам ударить…
                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                            • UFO just landed and posted this here
                                                                                                                                                +2

                                                                                                                                                VCS не про сеть, это просто контроль версий. А версии бывают и локальные. Git разделяет собственно контроль версий и работу с удаленными репозиториями, ка частный её случай. Для git существование удаленного репозитория — малозначащий в процессе разработки нюанс. Для svn — основа процесса.


                                                                                                                                                Git именно что позволяет разрабатывать не думая о существовании сетевых репозиториев пока не решишь залить код в сетевой репозиторий или получить обновления. SVN же принуждает работать с сетевым репозиторием, даже если вообще удаленный репозиторий не нужен, если ни с кем делиться не собираешься.

                                                                                                                                                • UFO just landed and posted this here
                                                                                                                                                    0
                                                                                                                                                    VCS нужна для обеспечения совместной работы

                                                                                                                                                    Вот, наверное, откуда ваше неприятие git и подобных систем. Вам она нужна только для обеспечения совместной работы, а я использую её для обеспечения работы вообще, о том, что она совместная — нюанс, о котором вспоминаю только когда нужно поделиться своими результатами или получить чужие. Но коммиты, создание веток, переключение между ними, слияние и т. п. — это не касается этого нюанса, это просто обычный процесс работы, независимо от того, совместная она или нет, создан сетевой репозиторий или нет. И бэкапами сложно заменить, с одной стороны, а с другой, можно представить локальную работу с гит как удобную систему работы с множеством бэкапов, просмотром диффов между ними, отслеживанием связей какой от какого "вырос", слиянием и т. т.п.

                                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                                        +1

                                                                                                                                                        Мне нужны "костыли", чтобы этого не нужно было помнить, особенно когда в рамках одного проекта делаю несколько задач параллельно. Да даже при чисто линейной разработке (что большая редкость) последовательность коммитов в VCS куда удобнее, чем последовательность обычных бэкапов. "Вкалывают роботы — счастлив человек" ©

                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                            0

                                                                                                                                                            И так со всеми своими проектами помните последовательность? За все "около 18 лет"? А что делаете когда важна не временная последовательность, а логическая? Её тоже помните?


                                                                                                                                                            Зачем куда-то что выгружать? Всё дерево истории можно прямо из каталога проекта смотреть, хоть содержимое файлов в коммите, хоть различия содержимого в любых коммитах в любых ветках. Да, можно сделать что-то похоже на снэпшотах/бэкпах, сделать в проекте папочку backups, в ней с пяток минимум папочек типа "production", "redesign", "feature-1", "bugfix-2" и т. п., в них папочки на каждій значимій шаг с комментирующим названием типа "merge with feature-1", "redesign logo", "add mock for backend", "workaround" и т. п., копировать туда проект после каждого шага, сравнивать их между собой стандартным diff-ом, сливать как-то. Но в итоге получится папочка типа .git

                                                                                                                                                            • UFO just landed and posted this here
                                                                                                                                                              +1

                                                                                                                                                              Вот буквально вчерашний пример. Откопал сайт, к которому не прикасался год. Делал его я один, соответственно никакой удалённый репозиторий ради командной разработки не был нужен. Откопал, потому что заметил, что один пункт меню пропал (не слишком важный пункт, поэтому целый год никто ничего не замечал). Открываю nav.html — нету пункта. При этом я точно помню, что этот пункт раньше был. Соответственно, логично захотелось посмотреть, каким nav.html был раньше.


                                                                                                                                                              Что бы было, если бы были только бэкапы? Да ничего. Народ обычно удаляет старые версии бэкапов (особенно через целый год-то), вот и я бы тоже удалил всё старое и оставил бы только последний актуальный бэкап. Но предположим, все старые бэкапы есть — и как бы я в них искал, когда пропал пункт меню из nav.html? Сидеть распаковывать десятки-сотни архивов и смотреть содержимое nav.html в каждом? Данунафиг блин.


                                                                                                                                                              Но зато у меня есть локальный репозиторий git! Простейший git log nav.html — и вот я уже вижу все изменения этого конкретного файла. Не прошло и минуты, а я уже нашёл коммит, в котором пункт меню пропал. 4 апреля 2016, описание «Rewrite nav.html». Всё стало ясно: отрефакторил файлик, а пункт меню просто забыл добавить и не заметил. В итоге я просто скопировал пункт меню из старого nav.html в новый, не пришлось писать ни строчки нового кода. git add nav.html && git commit -m 'Restored some nav items'


                                                                                                                                                              Пример примитивный, но ничего не мешает случиться чему-нибудь аналогичному на более глобальных изменениях, вроде выпиливания большой фичи, которую внезапно понадобится вернуть. Бэкапы — не замена контролю версий, контроль версий — не замена бэкапам. Если вы способны помнить всё, что делали во всех своих проектах, к которых не прикасались годами — поздравляю, у вас на удивление хорошая память, такая очень мало у кого есть :) А я помнить не только не могу, но и не хочу: зачем, если помнить за меня может обладающий бесперебойной памятью git, причём не требуя удалённого репозитория?) А крутить в голове я лучше буду те проекты, которыми занимаюсь в настоящий момент, а вышеупомянутый сайт к ним не относится.


                                                                                                                                                              С VCS надо куда-то выгружать данные

                                                                                                                                                              О чём тут речь? В моём случае кроме git add и git commit я ничего не делал, а просмотреть всё могу как простым git log, так и каким-нибудь графическим gitk

                                                                                                                                                              • UFO just landed and posted this here
                                                                                                                                                                  +2

                                                                                                                                                                  Что ж, поздравляю, вы уникальный :) Мне (и, думаю, многим другим) в первую очередь нужны и важны именно логи.


                                                                                                                                                                  Перед крупными изменениями я бэкаплюсь, а мелкие восстановить — дело пары минут.

                                                                                                                                                                  Даже спустя год? И храните все столь старые бэкапы? Вы всё ещё уникальный, можете гордиться этим))

                                                                                                                                                                    0

                                                                                                                                                                    Ну кстати, если графику в бэкапы не включать — смысл их удалять вообще? Код весит не так много, и отлично сжимается зипом :)


                                                                                                                                                                    Я регулярно создаю бэкапы перед крупными изменениями, а старые никогда не удаляю. Пример: был сайт, который я делал и поддерживал примерно год. За это время накопилось 40 бэкапов клиентской части и 32 бэкапа админки. Плюс следующие два года я поступал немного по-извращенски, внося вручную изменения в самые последние 1-2 архива во время важных security-фиксов и исправлений крупных багов.


                                                                                                                                                                    Проект довольно крупный. При этом мне ни разу даже в голову не пришло удалить какие-то старые архивы. Так что я с коллегой солидарен, пока код знаешь хорошо, и есть бэкапы (в идеале ещё и с краткими чейнджлогами) — VСS вообще не особо нужна.

                                                                                                                                                                      +2

                                                                                                                                                                      Если пользовать VCS, бэкапы вообще не особо нужны. ;)


                                                                                                                                                                      Хранение и просмотр изменений — непосредственная задача VCS. Пытаться адаптировать под это бэкапы — костыль и жевание кактуса. Делать по новому бэкапу с чейнджлогом на каждое мелкое изменение — какая-то глупость, а для VCS (кроме SVN, я так понимаю, лол) совершенно нормальная и очень полезная практика. И для VCS никакой графики выпиливать не надо.)


                                                                                                                                                                      примерно год. За это время накопилось 40 бэкапов

                                                                                                                                                                      В то время как сделать 40 коммитов к гите дело нескольких дней — история получается в разы подробнее, а откатывать отдельные изменения в случае чего (да, их иногда приходится откатывать) гораздо проще.


                                                                                                                                                                      пока код знаешь хорошо

                                                                                                                                                                      Вы тоже из тех, кто способен помнить старые крупные проекты годами? Ох, вас уже целых двое.

                                                                                                                                                                        0

                                                                                                                                                                        последовательные бэкэпы с ченжлогами и есть примитивная VCS по сути :)

                                                                                                                                                              0
                                                                                                                                                              А вы видать сложней визиток ничего не делаете)) Тут да, даже свн не нужен
                                                                                                                                                              • UFO just landed and posted this here
                                                                                                                                                                  +1
                                                                                                                                                                  Я не вижу смысла разбазаривать ресурс мозга на то, чтобы помнить в каком там каталоге лежит та версия, на которую понадобилось откатиться.
                                                                                                                                                                  Мне приятно грепнуть по комит меседжу в истории номер таски и спокойно увидеть в IDE дифф к текущей ситуации… или между произвольными моментами времени.

                                                                                                                                                                  И да, помнить 20-30-100мб текста наизусть? Вы серьезно? Или всеже у вас не такие серьезные проекты, как вам кажется?
                                                                                                                                                                  • UFO just landed and posted this here
                                                                                                                                                            +1
                                                                                                                                                            Если проект командный и у меня вдруг нет интернетов, я буду спокойно сидеть и кодить, а потом, когда сеть появится — залью всё одним коммитом. Никто от этого не пострадает, в комментарии к коммиту я просто напишу чуть больше.

                                                                                                                                                            То есть идея про атомарные изменения вам чужда?

                                                                                                                                                            • UFO just landed and posted this here
                                                                                                                                                                0
                                                                                                                                                                Что считать атомарным изменением?

                                                                                                                                                                Одну задачу.


                                                                                                                                                                Я вот, например, регулярно сначала одним коммитом делаю собственно доработку (багфикс или изменение), а потом следующим — рефакторинг. Так по истории легче определить, зачем сделано конкретное изменение.

                                                                                                                                                          +1
                                                                                                                                                          Когда не подключен к интернету — зачем тебе VCS? Сидишь, кодишь локально,

                                                                                                                                                          Чтобы внести одно сложное изменение, потом начать вносить следующее, имея легкий откат обратно. Я за собой заметил, что я иногда делаю локальные репозитории даже на присланных партнерами сэмплах, чтобы легко отличать мои изменения от их кода.

                                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                                              +1
                                                                                                                                                              Я просто не редактирую напрямую чужой код. Мне присылают архив, я распаковываю его, но не удаляю. Таким образом у меня всегда есть копия оригинального кода.

                                                                                                                                                              … а потом надо найти, какие изменения вы сделали, чтобы заработало.


                                                                                                                                                              Откаты же мне практически никогда не требуются, потому что я заранее знаю, что и как хочу написать.

                                                                                                                                                              Да вы гений. Или просто у вас очень простая система.


                                                                                                                                                              Но опять же — архивы, бэкапы. Мне норм.

                                                                                                                                                              Вам "норм", а кто-то не любит использовать костыли там, где за них уже написано решение.

                                                                                                                                                        0
                                                                                                                                                        За свои скромные 4.5 года в веб-разработке ниразу с таким не сталкивался.
                                                                                                                                                        Ни разу даже не слышал от коллег о подобной проблеме ни в одной из 3 компаний, где довелось поработать.

                                                                                                                                                        Сходите чтоли к бабке, пусть сглаз снимет. Яйца там откатает или что они еще делают.
                                                                                                                                                        зы. В лифтах не ездите только, от греха подальше
                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                      +1
                                                                                                                                                      Нет никаких проблем с настройками и правами. Просто почему-то рушатся локальные данные.


                                                                                                                                                      Вас не смущает, что у других подобных проблем не возникает?))))))))
                                                                                                                                                      • UFO just landed and posted this here
                                                                                                                                                          0
                                                                                                                                                          Ох блин… Повелись на толстого-толстого тролля ((((
                                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                                              +2

                                                                                                                                                              С чего вы взяли проблемы с памятью? Зачем мне запоминать в какой последовательности я что делал 10 лет назад?

                                                                                                                                                                +2
                                                                                                                                                                Напрасно вы считаете это троллингом.

                                                                                                                                                                Нет, не напрасно. Иначе просто объяснить подобное нельзя)

                                                                                                                                                                оказывается, у большинства разработчиков проблемы с памятью

                                                                                                                                                                о_О серьезно? Т.е. вы без проблем можете помнить все изменения в коде, например, размером 200мб? Вот 2 проекта, над которыми работаю параллельно в последнее время:


                                                                                                                                                                Никогда не поверю, что кто-то может помнить такой объем. Отсюда вывод — вы троль.

                                                                                                                                                                Как средство командной работы же он менее удобен, чем SVN, как раз из-за своей хвалёной децентрализации.

                                                                                                                                                                Лол… Именно локальное хранилище дает большие плюсы. Я вот часто делаю различные эксперименты с помощью гита и виртуалки и мне не приходится заливать ненужный код в общий репозиторий.

                                                                                                                                                                Там по ссылке вам правильно сказали — вы просто не смогли осилить. И поэтому решили всех троллить, в надежде найти поддержку. Но ее не будет, потому как svn реально говно, по сравнению с git/hg.
                                                                                                                                                                  0

                                                                                                                                                                  У вас просто реально очень крупные проекты, в этом случае, конечно, весь код помнить не реально. Но я всё равно не верю, что вы там правите ВСЁ.


                                                                                                                                                                  Обычно разработчик в большом проекте берёт себе одну задачу. Как правило — небольшую, особенно если он не тимлид (но тимлид хотя бы сам не пишет особо код, так что тут тоже проще). А так разбиваются на команды, и над одним модулем работают человека 2-4. Вот честно скажите, вам при работе над модулем надо помнить ВЕСЬ код проекта? Правда?


                                                                                                                                                                  Интеграция модуля в систему — это да, но API обычно чётко определены, и меняются редко. Да и API обычно делают с ядром, а не со всем на свете.

                                                                                                                                                                    +2
                                                                                                                                                                    А как на счет того, что ингда с вашим кодом работает ктото другой? Частые коммиты с внятными меседжами своего рода десижен лог. Открыв историю файла любой разработчик сориентируется не только кто, когда и в какой ветке сделал изменение, но и почему он его сделал
                                                                                                                                                                      0

                                                                                                                                                                      Ну тут конечно VCS незаменима. Я про индивидуальную разработку говорил


                                                                                                                                                                      А начался вообще этот тред со спора, нужен ли локальный репозиторий.


                                                                                                                                                                      Моя позиция была в том, что если не делать коммиты очень мелкими (2-3 строчки кода, не являющиеся цельным изменением) — то такой коммит не нужен. А если строчек много, и есть одно или более значимых функциональных изменений — то можно в ряде случаев и в сетевой репозиторий коммит залить. Тут уже как разработчики договорятся/как в компании принято.

                                                                                                                                                                      +1
                                                                                                                                                                      Но я всё равно не верю, что вы там правите ВСЁ.

                                                                                                                                                                      Очень зря. По первому проекту примерно 30 коммитов в сутки на команду (от меня лично — 3-4). Думаю это видно на скрине ;) И да, затрагивается абсолютно весь код, какой-то чаще, какой-то реже.

                                                                                                                                                                      Вот честно скажите, вам при работе над модулем надо помнить ВЕСЬ код проекта? Правда?

                                                                                                                                                                      Скажите честно — вы хоть раз работали в команде на 10-20 человек над большим проектом? Просто судя по заданному вопросу — нет. Тогда мне сложно будет вам объяснить, что как-раз НЕ НАДО помнить весь код (и особенно последние изменения) — их можно посмотреть в гите.

                                                                                                                                                                      но API обычно чётко определены, и меняются редко.

                                                                                                                                                                      Realy?)))) Я даже не знаю что сказать, если честно. Посмотрите на 2-й скрин, в котором код поменьше. За последние 5-6 месяцев в этом проекте переписано процентов 80 кода. Как думаете — апи остался без изменений?))))
                                                                                                                                                      +1
                                                                                                                                                      Позволяет разделять задачу на мелкие подзадачи и выполнять их отдельными коммитами

                                                                                                                                                      А почему нельзя каждую подзадачу коммитить в ветку непосредственно? Не вижу в этом большой проблемы. И имхо, во многих крупных проектах делают именно так. Глянуть хотя бы репозиторий хромиума или SKIA какой-нибудь. Там довольно небольшие коммиты и мелкие изменения.

                                                                                                                                                        0
                                                                                                                                                        А почему нельзя каждую подзадачу коммитить в ветку непосредственно?

                                                                                                                                                        Вы, наверное, имели в виду "в ветку удаленного репозитория". Так вот, потому, что код на этом этапе может быть еще не полностью готов — и, например, не проходить весь набор тестов.


                                                                                                                                                        Я вот, скажем, регулярно первым коммитом пишу тест (особенно если это баг). Если это попадет в общий репозиторий с CI, там начнут валиться билды.

                                                                                                                                                          0

                                                                                                                                                          Окей, с тестом — согласен, логичный сценарий.


                                                                                                                                                          В общем же случае — я бы просто не коммитил до тех пор, пока код не станет готов, и все тесты не будут им пройдены.


                                                                                                                                                          Так вот, потому, что код на этом этапе может быть еще не полностью готов — и, например, не проходить весь набор тестов.

                                                                                                                                                          Но если задача столь сложна, что за вечер или два её не решить — да, Вы правы, Git будет удобнее.


                                                                                                                                                          Хотя наверное можно извратиться и коммитить такие куски, чтобы тесты не падали. Но это потребует изрядной смекалки и лишних сил. Этот ресурс можно на другое пустить :)

                                                                                                                                                            +1
                                                                                                                                                            В общем же случае — я бы просто не коммитил до тех пор, пока код не станет готов, и все тесты не будут им пройдены.

                                                                                                                                                            … и все это время вам нельзя отрываться от задачи. Это, конечно, круто, но не всегда достижимо.


                                                                                                                                                            Но если задача столь сложна, что за вечер или два её не решить — да, Вы правы, Git будет удобнее.

                                                                                                                                                            У меня есть задачи, которые "решаются" неделями. И за это время я их на сервер пушу только из-за паранойи "а вдруг диск накроется" — и при этом я имею иногда почасовую историю того, что и зачем я делал, с соответствующими записями в blame/annotate.

                                                                                                                                                              0

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

                                                                                                                                                                0

                                                                                                                                                                У меня много задач параллельно. У меня, конечно, по ветке на каждую задачу, но, повторюсь, я не хочу, чтобы в общий репозиторий попадал неконсистентный код. А в локальном репозитории я могу творить, что угодно.

                                                                                                                                                          0
                                                                                                                                                          А почему нельзя каждую подзадачу коммитить в ветку непосредственно?


                                                                                                                                                          На это есть огромная куча причин. Основная — в истории желательно видеть кто и что сделал В ПРЕДЕЛАХ конкретной задачи. Если над задачей работает несколько человек — это вообще критично становится. Если один — желательно видеть, какой коммит за какую часть задачи отвечает (хотя-бы для ревью, но это так-же важно для тестов и выкладки).
                                                                                                                                          0

                                                                                                                                          Что значит "только diff"? Объясните поподробнее. И как бы это, объём данных, которые приходится выкачивать при клонировании Git репозитория, сильно удручает. Для больших проектов это целые десятки гигабайт.

                                                                                                                                            0
                                                                                                                                            И как бы это, объём данных, которые приходится выкачивать при клонировании Git репозитория, сильно удручает. Для больших проектов это целые десятки гигабайт.

                                                                                                                                            А вам точно нужна вся история и все ветки?

                                                                                                                                              0

                                                                                                                                              Нет, нужен только мастер, разумеется. Да, я глупость сказал. Проблема того проекта, о котором я пишу, не в том, что в качестве VCS там используется Git, а в том, что там просто используется много всего. И это всё нельзя не скачать, иначе код не скомпилировать просто.

                                                                                                                                            –1
                                                                                                                                            Пост от 2013-го года

                                                                                                                                            Это называется "слышал звон, да не знает, где он". Видно, что вы вообще не разбираетесь в сути вопроса.


                                                                                                                                            По пунктам:


                                                                                                                                            Первого марта 2005 года было продемонстрировано первое использование указанной уязвимости на практике. Группа исследователей представила два сертификата X.509 с разными наборами ключей, но с идентичными контрольными суммами. В том же году Властимил Клима опубликовал алгоритм, позволяющий обнаруживать коллизии на обычном ноутбуке за несколько часов. В 2006 он пошел дальше. Восемнадцатого марта 2006 года исследователь обнародовал алгоритм, находящий коллизии за одну минуту!

                                                                                                                                            Найти коллизию для некоторых двух хэшей — не то же самое, что взломать конкретный хэш (найти некие исходные данные, которые вернут ту же контрольную сумму). Это сильно разные задачи, и вероятность успеха сильно разная.


                                                                                                                                            Большая работа была также проделана и для ускорения взлома хешей. В 2007 году Кевин Бриз представил программу, использующую Sony PlayStation3 для взлома MD5. Он сумел добиться очень неплохих результатов: 1,4 миллиарда MD5-хешей генерировались всего лишь за одну секунду!

                                                                                                                                            Давайте посчитаем: за месяц с такой скоростью можно получить примерно 3628800 миллиардов хэшей. Посмотрим, как это соотносится с длиной хэша (128 бит). Math.log2(3628800000000000) = 51.688413968703216. Это даже не квадратный корень от общего числа комбинаций. Но даже если бы это был корень, чтобы подобрать все хэши, понадобилось бы примерно… 302400000000000 лет. Лет, Карл!


                                                                                                                                            Мы используем вышеприведенный способ для взлома одного определенного хеша, сгенерированного при помощи алгоритма MD5. Максимальная длина возможного пароля составляет семь символов. Через какое-то время пароль будет найден (qwerty). Теперь давай попробуем взломать еще один хеш, но с немного другими условиями. Пусть наш хеш имеет вид d11fd4559815b2c3de1b685bb78a6283, а пароль включает в себя буквы, цифры, знак подчеркивания и имеет суффикс «_admin». В данном случае мы можем использовать перебор пароля по маске, чтобы упростить программе задачу

                                                                                                                                            Теперь давай попробуем взломать сразу несколько паролей одновременно. Предположим, что к нам в руки попала база данных хешей паролей. При этом известно, что каждый пароль оканчивается символами c00l

                                                                                                                                            В реальной жизни, если пароль не имеет вид "111111", задачу упростить таким образом не получится. Последний пример (с одинаковыми постфиксами на всю пользовательскую базу) — вообще сферический идиотизм в вакууме, в жизни такого не бывает.

                                                                                                                                              0
                                                                                                                                              Видно, что вы вообще не разбираетесь в сути вопроса.


                                                                                                                                              Оохх… Ну ок, пусть будет «не разбираюсь»)). Мне реально не хочется с вами на эту тему общаться.
                                                                                                                                                –1

                                                                                                                                                Также важно помнить, что стойкость хэш-суммы имеет значение лишь в случае, когда база утекла с сервера. Если база утечёт — скорее всего, админ об этом узнает. В этом случае ответственный админ сразу же сбросит пароли всем пользователям. Если сайт совсем не содержит критических данных (небольшой блог или форум) — то и вовсе можно сделать рассылку и предоставить пользователям решить самостоятельно, хотят они обновить свой пароль или нет. Тут мне могут возразить, что такая утечка ставит под удар доступ юзера ко ввсем ресурсам, где есть такой же пароль. Но пароли всё равно меняют раз в 1-2 года самое крайнее, а как правило намного чаще.


                                                                                                                                                Я к тому, что даже 2-3 месяца в запасе — уже немалый срок. Те же цифры, что я посчитал, хоть они и взяты не на текущий год, а на тот год, про который писалось в статье — они настолько астрономические, что, кхм, вряд ли что-то существенно поменялось.


                                                                                                                                                Предлагаю в общем всем желающим провести простой эксперимент. Берёте пароль длиной 7-8 символов, сгенерированный случайно, объединяете с 32-символьной солью (тоже псевдослучайной), получаете MD5 хэш. Скачиваете соответствующий софт и пробуете взломать. И потом увидим, сколько времени для этого понадобится, и выйдет ли оно вообще.


                                                                                                                                                Я даже хэшей могу накидать для такого теста.

                                                                                                                                                  +1
                                                                                                                                                  Ну хорошо, 1 раз отвечу…

                                                                                                                                                  Если база утечёт — скорее всего, админ об этом узнает.

                                                                                                                                                  Не узнает.

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

                                                                                                                                                  Если в здравом уме — нет.

                                                                                                                                                  Но пароли всё равно меняют раз в 1-2 года самое крайнее, а как правило намного чаще.

                                                                                                                                                  99% нет.

                                                                                                                                                  Те же цифры, что я посчитал, хоть они и взяты не на текущий год, а на тот год, про который писалось в статье — они настолько астрономические, что, кхм, вряд ли что-то существенно поменялось.

                                                                                                                                                  1. В посте говорилось про взлом/исследование на ноуте/PS3/видюхе.
                                                                                                                                                  2. Берете кластер в амазон/google и все меняется настолько существенно, что…

                                                                                                                                                  Берёте пароль длиной 7-8 символов, сгенерированный случайно

                                                                                                                                                  А пароли пользователи выбирают такие-же? По вашему, радужные таблицы не нужны в реальности?)))

                                                                                                                                                  Вы бы хоть основы поизучали… Меня обвинили в том, что я в этом не разбираюсь, при этом пишите такие глупости, которые я лично проходил на своем опыте… Не позорились-бы…
                                                                                                                                                    0

                                                                                                                                                    Не согласен почти ни с одним пунктом)


                                                                                                                                                    Не узнает.

                                                                                                                                                    Может узнать. Например, хостер доведёт до сведения, или взломщик по глупости оставит следы своего присутствия. В крупных проектах, например, есть специальные люди, которые мониторят логи. В них что-то может остаться.


                                                                                                                                                    99% нет.

                                                                                                                                                    Может Вы и правы. Но это зря) Лучше менять раз в полгода хотя бы, особенно в критичных местах.


                                                                                                                                                    В посте говорилось про взлом/исследование на ноуте/PS3/видюхе.

                                                                                                                                                    Насколько я знаю, видюха даёт выигрыш всего на 2-3 порядка. Это не так много.


                                                                                                                                                    Берете кластер в амазон/google и все меняется настолько существенно, что…

                                                                                                                                                    Да ладно) И насколько? И сколько это будет стоить?


                                                                                                                                                    Если в здравом уме — нет.

                                                                                                                                                    А вот этого я совсем не понял… Объясните, пожалуйста, почему. Если главная цель — защитить пользователей, логично сбросить пароли, разве нет? Иначе есть риск взлома аккаунтов.


                                                                                                                                                    А пароли пользователи выбирают такие-же?

                                                                                                                                                    Вообще-то да. Это в любой инструкции для чайников указано, вы чего. Да и по своим знакомым я знаю, какие пароли ставят на критичные сервисы, например, на админки своих собственных проектов.


                                                                                                                                                    Вы бы хоть основы поизучали…

                                                                                                                                                    Да я же не против совсем. Просто тут очень агрессивно все нападают, вместо того, чтобы просто указывать на оплошности. После такого и желание изучать что-то у многих пропадает… :)

                                                                                                                                                      +2
                                                                                                                                                      «Может узнать» и «Если база утечёт — скорее всего, админ об этом узнает» — немного разные вещи, не находите?

                                                                                                                                                      Например, хостер доведёт до сведения

                                                                                                                                                      Да ёлки-палки… Забудьте о «хостере». Во-первых, они точно не узнают, что вашу базу слили. Во-вторых, они не сообщат об этом, потому как это не их дело.
                                                                                                                                                      Не так давно был пост про yahoo. Взломали в 2013-м, узнали в 2016-м… Крупная компания. И где админы, которые легко узнают? Где спец.люди по логам? Где «хостер»?)))

                                                                                                                                                      В крупных проектах, например, есть специальные люди, которые мониторят логи

                                                                                                                                                      Серьезно? Можете дать примеры таких проектов? Вот честно — ни разу даже не встречал упоминание подобного, хотя вроде знаю разработчиков/админов/владельцев некоторых крупных проектов.

                                                                                                                                                      Лучше менять раз в полгода хотя бы, особенно в критичных местах.

                                                                                                                                                      Хм… Я вроде не говорил это давать возможность/заставлять менять пароли пользователями — плохо. Я сказал, что админ не будет менять. Об этом ниже.

                                                                                                                                                      А вот этого я совсем не понял… Объясните, пожалуйста, почему. Если главная цель — защитить пользователей, логично сбросить пароли, разве нет? Иначе есть риск взлома аккаунтов.

                                                                                                                                                      Потому, что это точно не задача админа. Даже больше — админ не имеет права вносить правки ни в код, ни в базу. При любом раскладе. За подобное увольняют без вопросов, не зависимо от причин.

                                                                                                                                                      Насколько я знаю, видюха даёт выигрыш всего на 2-3 порядка. Это не так много.

                                                                                                                                                      Хм… Давайте подумаем… 2-3 порядка от 2млрд — это 0,2-2трлн хешей в секунду. До сих пор считаете что это «не так много»?

                                                                                                                                                      Да ладно) И насколько? И сколько это будет стоить?

                                                                                                                                                      А какая разница?))) Вот 2 сценария:
                                                                                                                                                      1. Необходимо поломать наибольшее количество аккаунтов пользователей google/yahoo/yandex. Скорее всего (пруфов нет), у 1% пользователей будет 1 пароль на акк и на платные сервисы различных систем. Предположим, есть 1млрд аккаунтов, значит 1% даст 10млн потенциальных жертв (не говоря о побочных «плюсах» в виде переписок, например). Так-же предположим, что пароли у этих «жертв» не сложные (иначе они не попадают под первое условие — 1 пароль на разные аккаунты). Кластер обеспечит несколько триллионов хешей в секунду, что составляет n * 86400 * 31 трл хешей в мес (довольно большая цифра, согласитесь). Имеет смысл потратить на это пару-тройку тысяч долларов? Имеет. Даже не пытайтесь спорить)
                                                                                                                                                      2. То-же самое, но на коммерческой основе, когда предоставляем услуги по взлому тем, кому дорого/лень организовывать платформу. Тут намного выгоднее. платим пару-тройку тысяч долларов, но берем по 1$ за каждый аккаунт (а их, как посчитали выше, с десяток миллионов).

                                                                                                                                                      Все еще думаете, что это очень дорого?)))

                                                                                                                                                      Вообще-то да. Это в любой инструкции для чайников указано, вы чего. Да и по своим знакомым я знаю, какие пароли ставят на критичные сервисы, например, на админки своих собственных проектов.

                                                                                                                                                      Да вы шутите))) Топ-10 паролей базы yahoo:

                                                                                                                                                      123456
                                                                                                                                                      password
                                                                                                                                                      welcome
                                                                                                                                                      ninja
                                                                                                                                                      abc123
                                                                                                                                                      123456789
                                                                                                                                                      12345678
                                                                                                                                                      sunshine
                                                                                                                                                      princess
                                                                                                                                                      qwerty

                                                                                                                                                      Пруф.

                                                                                                                                                      Топ-25 паролей взломанных сервисов в 2016-м году:


                                                                                                                                                      Продолжать или сами погуглите?)

                                                                                                                                                      Просто тут очень агрессивно все нападают, вместо того, чтобы просто указывать на оплошности.

                                                                                                                                                      Так вы слушайте, а не пытайтесь приводить в ответ очевидные глупости ;)
                                                                                                                                                        –1
                                                                                                                                                        И где админы, которые легко узнают? Где спец.люди по логам? Где «хостер»?)))

                                                                                                                                                        У Yahoo нет хостеров, они сами себе хостер, ну либо Амазон какой-нибудь используют. Но их взламывать гораздо перспективнее с точки зрения возможных "дивидендов", вот и желающих много. Логично, что кому-то удалось. А админы могли и просто замолчать факт утечки (а узнали, скорее всего, слишком поздно). Либо взломщик был настолько гениален, что вообще не оставил никаких следов, но я в это слабо верю. Хоть какие-то запросы он ведь делал. Просто логи видимо лень читать админам...


                                                                                                                                                        Серьезно? Можете дать примеры таких проектов?

                                                                                                                                                        Примеры, увы, не дам. Но как минимум на Хабре (или другом ресурсе) была статья, где в комментах человек писал, зачем это нужно. Там даже выражение устойчивое есть в админской среде — "курить логи". Если админы этого не делают — они или хреновые админы, или перегружены, и им не хватает сотрудников.


                                                                                                                                                        Для этого целые средства обработки логов создают для UNIX систем, между прочим. С выгребанием, разбивкой и обработкой в реальном времени. И мониторится абсолютно всё: обращения к серверам баз данных, обращения к фронтенду, обращения админов к админке… И одна из целей такой обработки — потенциально снизить объём для чтения админом, выкинув явный мусор.


                                                                                                                                                        Даже больше — админ не имеет права вносить правки ни в код, ни в базу. При любом раскладе.

                                                                                                                                                        Да ладно, "здрасте приехали". А кто блокирует доступ, например, к почтовому ящику, когда система обнаруживает, что ящик взломан, и пароль скомпрометирован (взять к примеру мейл.ру или всем известный вк)? Автоматика, скажете вы. Но ведь эту автоматику писали программисты. С согласия руководства проекта :)


                                                                                                                                                        А если автоматики по каким-то причинам нет, или она своевременно не сработала, но точно известно, что аккаунт взломан — это кто же запретит компании заблочить аккаунт пользователя? Вы серьёзно? Понятно, что это действие, возможно, не в полномочиях простого админа. Хотя, если фирмочка маленькая, и админу явно разрешили такие действия прямым текстом — то может даже, это как раз его задача.

                                                                                                                                                          0
                                                                                                                                                          А админы могли и просто замолчать факт утечки (а узнали, скорее всего, слишком поздно). Либо взломщик был настолько гениален, что вообще не оставил никаких следов, но я в это слабо верю. Хоть какие-то запросы он ведь делал. Просто логи видимо лень читать админам...


                                                                                                                                                          Но как минимум на Хабре (или другом ресурсе) была статья, где в комментах человек писал, зачем это нужно. Там даже выражение устойчивое есть в админской среде — «курить логи». Если админы этого не делают — они или хреновые админы, или перегружены, и им не хватает сотрудников.


                                                                                                                                                          Как Вы выше сказали? «Слышал звон, да не знает где он»?)))

                                                                                                                                                          Для этого целые средства обработки логов создают для UNIX систем, между прочим. С выгребанием, разбивкой и обработкой в реальном времени. И мониторится абсолютно всё: обращения к серверам баз данных, обращения к фронтенду, обращения админов к админке…


                                                                                                                                                          Да ладно? Серьезно? «А мужики-то не знают»))). Ну реально, для чего вы говорите примитивные вещи? Вы хотя-бы представляете объем логов более-менее среднего проекта?

                                                                                                                                                          И одна из целей такой обработки — потенциально снизить объём для чтения админом, выкинув явный мусор.

                                                                                                                                                          Нет.

                                                                                                                                                          А кто блокирует доступ, например, к почтовому ящику, когда система обнаруживает, что ящик взломан, и пароль скомпрометирован (взять к примеру мейл.ру или всем известный вк)? Автоматика, скажете вы. Но ведь эту автоматику писали программисты. С согласия руководства проекта :)

                                                                                                                                                          Вы вроде про админов начинали отвечать, а пришли к программерам и руководству)))) Что-то тут не так с логикой ответа))

                                                                                                                                                          А если автоматики по каким-то причинам нет, или она своевременно не сработала, но точно известно, что аккаунт взломан — это кто же запретит компании заблочить аккаунт пользователя?

                                                                                                                                                          Никто. Просто потом уволят и все… Есть правила. Вы хоть основы работы команд изучите, прежде чем подобное заявлять…

                                                                                                                                                          Хотя, если фирмочка маленькая, и админу явно разрешили такие действия прямым текстом

                                                                                                                                                          То в этой «фирмочке» огромные проблемы. Вас совсем не смущает тот факт, что вместе с блокировкой какого-то аккаунта могут выполняться дополнительные действия (логирование, запрет доступа в другие подсистемы, отправка информации о блокировке менеджерам/программистам, остановка отправки смс/email уведомлений, etc)?! И тут приходит админ и шлёт нафиг всю логику, т.к. ему захотелось кого-то в базе забанить)))) Лол.

                                                                                                                                                          Когда речь идёт о числах с 18-25 нулями, то разница на 2-3 порядка — это и правда немного. Простая логика же. Да, всё ещё считаю.

                                                                                                                                                          Да ёлки-палки… Когда у вас число с 1-2 нулями — 2-3 порядка действительно не много, а когда с 18-25 — 2-3 порядка == огромное количество. Представьте, вы работали за компом с 1Ггц проца и вам дали с 0,1-1Тгц. Что скажете? «Да ладно, почти нет разницы»?)))))))))))))

                                                                                                                                                          Таких людей тоже стоит учитывать :)

                                                                                                                                                          Исключения есть всегда, но они, обычно, подтверждают правила ;)

                                                                                                                                                          Вплоть до 20-40 процентов, как подсказывает логика :)

                                                                                                                                                          Ну тогда такие пользователи как вы вообще не интересны взломщикам. Что вы есть, что вас нет — не принципиально)

                                                                                                                                                          Вы слишком упрощаете.

                                                                                                                                                          Серьезно?))))

                                                                                                                                                          Тут нужен или очень богатый покупатель, или очень много покупателей. Дай бог вы продадите 5-10 процентов.

                                                                                                                                                          Никому подобного не говорите))))

                                                                                                                                                          Я уже молчу о том, что если спалиться на таком, можно и перед законом ответить — не все рискнут взяться за это дело.

                                                                                                                                                          Чего?! В каком законодательстве запрещен подбор хешей?! Я что-то пропустил?! Ну хватит нести бред-то!

                                                                                                                                                          Тут надо иметь пару-тройку тысяч долларов, которые не жалко на такое пустить, и уметь организовать такой кластер.

                                                                                                                                                          Перечитайте мои предыдущие комменты. Пара-тройка тысяч — копейки, если необходимо взломать несколько миллионов аккаунтов ;) Это примерно зар.плата 1 (ОДНОГО) программиста ;)

                                                                                                                                                          Ну и самое главное — надо перед этим получить утекшую базу данных :)

                                                                                                                                                          Это уже из другой оперы. Мы-же говорили про md5 и пр. ;)

                                                                                                                                                          Кстати, я вообще не очень хорошо представляю, как можно слить базу в системе, которая достаточно надёжна защищена.

                                                                                                                                                          Вариантов море. От кривого сервисного софта до sql-inj.

                                                                                                                                                          Можно слить её шеллом, даже не зная структуры — это, кажется, логично. Но в нормально защищённую систему нельзя залить шелл.

                                                                                                                                                          Чего?! Это шутка? Шелл юзают для получения доступа к системе, для повышения привелегий и еще много для чего, но точно не для того, чтобы слить базу))). А залить шелл можно очень часто. Есть загрузка аватарок/изображений — есть потенциальная дыра. Используются get-параметры — есть потенциальная дыра. И т.д.

                                                                                                                                                          Феерический идиотизм. Ибо подобрать такое даже проще, чем дату рождения. Для подбора такого пароля даже не нужно лично знать пользователя, чтобы взломать его аккаунт. :)

                                                                                                                                                          Так я вам про это выше и говорил — большинство пользователей поступают именно так. Причин для этого нет (адекватных), но большинство людей очень далеки от ИБ.
                                                                                                                                                            –1
                                                                                                                                                            > Вы хотя-бы представляете объем логов более-менее среднего проекта?

                                                                                                                                                            Но это почему-то никому не мешает их читать, даже в крупных проектах))

                                                                                                                                                            > Как Вы выше сказали? «Слышал звон, да не знает где он»?)))

                                                                                                                                                            Я в любом случае не скажу вам, в какой компании тот человек работал, но что такое было на одном из форумов, и я это читал — это факт.

                                                                                                                                                            > Никто. Просто потом уволят и все… Есть правила.

                                                                                                                                                            Слушайте, ну не надо нести откровенный бред. Кто кого уволит? Это нормальная практика. Если компания решила, что она блокирует аккаунты с подозрительной активностью, и очевидно, что такая активность была, но автоматический алгоритм «заглючил» и не сработал — конечно же, блокировку произведут вручную. Это может спасти от спам-рассылок или чего похуже — того, что может сделать взломщик, если аккаунт не заблочить и оставить как есть.

                                                                                                                                                            > И тут приходит админ и шлёт нафиг всю логику, т.к. ему захотелось кого-то в базе забанить)))) Лол.

                                                                                                                                                            Лолшто?)) Где я говорил «потому что админу захотелось»?.. Я сказал — если объективно есть необходимость в блокироввке, но автоматический алерт не сработал, и блокировка не произошла.

                                                                                                                                                            > Да ёлки-