Как правильно реализовать взаимодействие с бд на сайте?

Question

[xxyofu]

Я разрабатываю сайт для своих целей(проба пера), не понятно как правильно реализовать взаимодействие с базой данных, например, когда пользователь входит на сайт он заноситься в бд, то есть js отслеживает вход и делает post запрос php с данными для входа, но тогда любой пользователь может отправить такой же запрос, взяв за пример код js из кода элемента, вариант 2 из моей головы, использовать некий ключ, передаваемый в самом запросе, тогда как его хранить, например в env, из того что я вычитал, но тогда вопрос, а что мешает пользователю в том же коде элемента через console.log вывести содержимое этого файла и т.д. Подскажите как такие вещи правильно реализовать

Comments

[Михаил Ливач]

непонятно, как у вас всё устроено. распишите по шагам. Потому что из того, что вижу я, следует вот это:
1) пользователь заходит на сайт. Он не залогинен. В этот момент Вам не нужен js, POST запрос и прочее - вы отслеживаете GET запрос страницы;
2) пользователь в форме авторизации вводит логин и пароль, отправляет на сервер. Здесь вы защищаетесь от CSRF и проверяете данные: если всё валидно - отмечаете в базе, что хотите. Если не валидно - отдаёте ошибку. Велосипед с js и POST запросом опять же не нужен.

[Ипатьев]

Непонятно, что именно непонятно.

но тогда любой пользователь может отправить такой же запрос,

А в чем проблема-то? У вас сайт только для одного юзера что ли?
Обычно сайты делают для любых пользователей. И любой пользователь отправляет запрос на авторизацию. С чего вы решили, что пользователи не могут это делать?

Answer 1

[alexalexes]

использовать некий ключ, передаваемый в самом запросе, тогда как его хранить, например в env

Все придумано за вас, давно.
Некий ключ передаваемый в запросе - сессионная кука. Прочитайте про куки, и сикьюрные флаги кук - как http only и secure.
Прочитайте, что такое сессии php. Как она подымается, обратите внимание, когда появляется сессионная кука, и как она меняется от клиента к клиенту (потыкайте обычный режим браузера и инкогнито).
Посмотрите, как используется $_SESSION и $_COOKIE, чтобы сохранять данные авторизации, которые не передаются клиентом прямыми запросами.
Понимание работы с сессиями сервера и куками, не обязательно в PHP, даст исчерпывающий ответ на вопрос.

Answer 2

[キム ファイブプラス]

но тогда любой пользователь может отправить такой же запрос, взяв за пример код js из кода элемента

Нет, не может. CORS.

что мешает пользователю в том же коде элемента через console.log вывести содержимое этого файла

location ~* \.(env) {
    deny    all;
}

Если хотите понять как все устроено. Начните разбираться с взаимодействием через API.

Comments

[Rsa97]

Нет, не может. CORS.

CORS - это функция браузера. Отправить запрос можно и без браузера или через расширение (тот же Rester), на которое CORS не влияет.

[キム ファイブプラス]

Rsa97, Это проблема бэкенда, что и от кого обрабатывать. В вопросе об этом нет уточнения. Я не знаю что это за говнокод должен быть, чтобы XHR ориентированные запросы от фронта принимать с стороннего домена, если это не было предусмотрено.

[Ипатьев]

キム ファイブプラス, сначала расскажите нам, что такое "сторонний домен" в терминах протокола НТТР. Мы все с интересом послушаем.

Answer 3

[AlexVWill]

Подскажите как такие вещи правильно реализовать

Правильно такие вещи реализовать не самописно, а с помощью механизмов авторизации, придуманных профи. Вот так например: https://developers.google.com/identity/sign-in/web...
Крайне рекомендуют делать именно так, а не иначе, потому что позволяет а) понять идеологию и механизм реализации правильного решения б) избежать гемороя с хранением, обработкой и передачей данных учетных записей...

Comments

[Adamos]

ц) хлебнуть геморроя ковшиком, когда ГД в угоду ГБ это все запретит.

[Refguser]

Нет ничего боле дурнее ставить себя в зависимость от сторонних сервисов/контор/етс когда есть и более простые и надёжные методы.

ЗЫ. Как доп фича для юзеров - можно. Но ни как иначе.