Таким образом, у меня есть этот метод проверки черного ящика, переданный мне из аккаунтов, что в основном составляет ldap_bind($connection, $username, $password) . Но, конечно, я хочу, чтобы мои пользователи могли входить в систему, скажем, за 30 дней.
Наивный, но небезопасный способ справиться с этим состоит в том, чтобы сохранить имя пользователя и пароль в cookie открытого текста, а затем проверять их с помощью моего черного ящика каждый раз, когда пользователь посещает.
Как обычно работает, но не из-за моего черного ящика – хранить пароль пользователя в базе данных (или хранить хешированный?) И хранить хеш-версию в файле cookie, а затем сравнивать значения. Это не работает здесь, так как мой черный ящик требует фактического пароля, а не хешированного пароля.
Моя нынешняя мысль – это своего рода шифрование (в отличие от хэширования). Но так как это, очевидно, общая проблема, я подумал, что лучше всего сначала спросить, есть ли лучшее решение, лежащее вокруг, или, если нет, то, что вы предложите для метода шифрования / дешифрования.
Это не будет отвечать на ваш вопрос, но вы НЕ должны хранить ваши пароли пользователей, даже не зашифрованные.
Если вам действительно нужно это сделать, и пользователи понимают, что вы это делаете. затем сохраните пароль в базе данных вашего приложения (зашифрованный, конечно), а затем отправьте пользователю cookie с хешем. Когда пользователь хочет войти в систему, сравните хэш с тем, что вы сохранили, и только затем отправьте незашифрованный пароль в ldap. Никогда не отправляйте пароль (даже не зашифрованный) на машину пользователя.
Опять же, это очень плохая практика. если ldap не позволяет хранить сеансы / пароли, возможно, для этого есть веская причина.
когда пользователь входит в систему, дайте им случайно сгенерированный «сеансовый файл cookie» (не строго cookie сеанса, поскольку он будет длиться дольше, чем сеанс просмотра) и сохраните кортежи:
user_id | cookie_id
затем подключите cookie_id, присоединитесь к user_id со своей пользовательской таблицей и отпустите.