У пользователя хранится ID сессии в куки. Таким образом, если злоумышленник доберется до компьютера жертвы, он может просто скачать себе ее cookie?

DevMan, я уже попробовал. Убрал свои куки, открыл сайт - я не авторизован. Восстановил куки - я авторизован.
И у меня возник вопрос. Я сохранил куки. Вышел из vk. И снова вошел. И снова вышел.
Потом в хроме заменил куки на те, когда я был в vk до всех этих входов / выходов. И я стал авторизован. Почему? Ведь Для каждого пользователя PHPSESSID является уникальным и постоянным на весь сеанс работы. А я ведь вышел (окончил сеанс). Создал новый сеанс (вошел). И снова вышел. Потом заменил куки, где PHPSESSID старый. И я снова стал в сети. Как так?

У пользователя хранится ID сессии в куки. Таким образом, если злоумышленник доберется до компьютера жертвы, он может просто скачать себе ее cookie?

То есть, нужно всего лишь скопировать вот этот файл
`C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Cookies`
и вставить в свой хром? И если пользователь был авторизован в vk, например. После вставки я буду тоже авторизован?

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

sim3x, а куда лучше - в сессию или в БД? я новичок просто, не знаю. Я слышал, что сессию можно перехватить. И это проще, чем получить доступ к БД.

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

вызываем uuid.uuid4() и вставляем в сессию юзера

Почему в сессию, а не в БД?

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

Плох тем что злоумышленник получает доп информацию через апи, вызов которого вы не будете контролировать. Кто в здравом уме обратит внимание на 10М писем с восстановлением паролей?

Не понимаю. Можно вот тут по-подробнее?

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

АртемЪ, я и в исходниках других проектов видел соли. И они, как правило, из разных символов. А не просто одни и те же символы, но разное количество.
Для чего-то ведь сделали именно разные символы.

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

А можно пример с UUID + email?
Что такое UUID вообще? Чем плох метод создания хеша, который используется и для создания пароля?

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

Если у вас соль будет "1111111111111" это ничем не хуже чем скажем "hu89u7yG7^67f^7F6" - важна только длина, а не содержание.

Что-то совсем не верится. А можно какие-нибудь доказательства?

Статья на хабре про хеширование паролей. Непонятны некоторые моменты. Поможете разобраться?

На википедии написано, что длина соли - это 10-20 символов:
https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%BB%D...

Если же мы «посолим» пароль, то есть соединим строчку из 10—20 случайных символов с паролем и уже от этой строчки найдём MD5, — стандартные таблицы не будут работать, так как они не рассчитаны на поиск такой длинной строки.

А у вас целых 58.
Какой длины должна быть соль? И как ее лучше составлять?

Как хранится соль пароля?

Если при генерации хеша, используется каждый раз новая соль - она вполне может лежать открытым текстом рядом с хешом, или прямо в нем (несколько символов в начале, в конце или середине). Это позволяет для одинаковых паролей создавать разные хеши

Разные хеши - пока я не вычту эти "несколько символов" из готового хеша. Потом они станут одинаковыми. Верно?

БД SQL - нормальны ли magic numbers в БД, которые имеют константы в back end коде? Или лучше сделать таблицу и отношение?

А что мешает добавить новый пол в качестве константы в класс? Как и новый статус. Это ведь просто число.

БД SQL - нормальны ли magic numbers в БД, которые имеют константы в back end коде? Или лучше сделать таблицу и отношение?

Спасибо. А если сделать таблицу и отношение. При работе со статусом придется обращаться к БД, чтобы получить возможные статусы. Насколько это критично? Насколько хуже, чем обращаться к константе в классе php?

БД SQL - нормальны ли magic numbers в БД, которые имеют константы в back end коде? Или лучше сделать таблицу и отношение?

Евгений, тогда при работе со статусами будет еще одно лишнее обращение - к таблице statuses. А чем меньше обращений, тем лучше ведь, разве нет? Насколько это критично?

Статья на хабре - "Upgrade до Middle PHP-разработчика за 3 месяца". Если я не читал этих книг, но смог написать свой магазин, я все равно Junior?

Почему тогда у статьи так много положительных отзывов?

Все текстовые константы должны быть в файлах config. А почему нельзя создать php класс и занести их туда? Почему именно config файл?

DevMan, а можете дать ссылку на гитхаб? или где можно посмотреть.

Все текстовые константы должны быть в файлах config. А почему нельзя создать php класс и занести их туда? Почему именно config файл?

А где можно про это почитать поподробнее?

Все текстовые константы должны быть в файлах config. А почему нельзя создать php класс и занести их туда? Почему именно config файл?

А если нет, то никакое преимущество config перед классом не имеет?

Все текстовые константы должны быть в файлах config. А почему нельзя создать php класс и занести их туда? Почему именно config файл?

Тем более, если нет нужды в мультиязычности сайта.

Да даже если есть. Я не понимаю, чем класс. Например, "Messages". Отличается от файла config? Специальный класс для сообщений с текстовыми константами.

Чтобы удобнее переводить было (если сайт мультиязыный)

А класс что неудобно переводить что ли?

При изменении значения SELECT изменяется значение в БД (через AJAX). Нужно ли мне на клиенте отменять изменение SELECT и делать его вручную в success?

Пока запрос к серверу придет, пока обработается... Получится сначало изменение, а потом отмена. Как-то не очень красиво. Да и если товаров много, уже можно пролистать ниже / выше. И вообще не увидеть, что была ошибка.

Нужно ли как-то запрещать индексацию поисковиками админки, если при попытке зайти на нее обычному пользователю его перекидывает на главную страницу?

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