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

0

Если у меня есть база данных XML на моем веб-сервере;

<Database>
    <Client sid="0123456789abcdefg" name="John Doe" email="[email protected]" hash="9876543210abcdefg" salt="abcdefg9876543210">
        <Setting>A Setting</Setting>
        <Setting>Another Setting</Setting>
    </Client>
    ...
</Database>

И я вхожу в систему с хешем и солью, извлекаю SID и перенаправляю на домашнюю страницу через PHP;

header("Location: home.html?sid=" . $sid);

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

Есть ли лучший способ или более стандартный способ установки и получения пользовательских настроек в Интернете?

PS: Если у вас нет действительно веской причины, я действительно, действительно, действительно, не хочу использовать SQL. Я предпочитаю читать мои базы данных, и мне нравится осязаемость и универсальность XML.

Редактирование: после небольшого исследования я узнал, что PHP поддерживает систему хранения переменных SESSION []. Это идеально для меня, потому что я, по сути, использую сессии!

W3C говорит:

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

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

  • 0
    Вы не можете прочитать свою базу данных \ a * SQL ??
  • 0
    Нет, это просто ... Ну, база данных XML - это файл . Вот и все. SQL - это интерфейс, который, на мой взгляд, совершенно не нужен, потому что и PHP, и JavaScript способны читать XML через DOM.
Показать ещё 2 комментария
Теги:
hash

1 ответ

1
Лучший ответ

Пока ваш файл DB недоступен из HTTP (т.е. Заблокирован.htaccess или его эквивалентом) и другими протоколами (т.е. Не сидит в каталоге, доступном по анонимному FTP), единственный риск состоит в том, чтобы (случайно) позволить собирать хэш и соль кучу других данных, связанных с пользователем, и отправленных вашим клиентам.

Если у вас есть запросы, эквивалентные селектору SQL *, это может быть проблемой. Возможно, вы захотите перевести критические данные в другой файл DB и инкапсулировать обращения в интерфейс, предназначенный для регистрации пользователей и входа в систему, чтобы убедиться, что ни один другой фрагмент кода не сможет захватить их (даже по ошибке) из вашего основного DB.

  • 0
    Спасибо. Хорошо сказано.
  • 0
    Пожалуйста.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню