Полигон-2

m_emelchenkov написал:

[q]

Если каждый раз передавать идентификатор сессии в URL’е (GET-запросе).

[/q]

Это как бы одна из альтернатив cookie, вопрос как сделать вообще без замены.


m_emelchenkov написал:

[q]

Но это неудобно будет (запомнить юзера нельзя)

[/q]

Насчёт запомнить это вопрос спорный, а вот насчёт неудобно можно поподробней? Я так понимаю, что если не использовать ничего аналогичного cookie, то для работы с конкретным пользователем сервер перед каждым действием (приёмом / передачей информации) должен проводить аутентификацию? Вопроса получается два:
1. Нельзя ли было эти сеансы аутентификации спрятать внутри HTTP и браузера которых хранит пару логин-пароль и сделать незаметным для пользователя?
2. Как это работает без cookie и прочего в случае с FTP протоколом?


m_emelchenkov написал:

[q]

поэтому вопроса использовать их или нет даже не ставится.

[/q]

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

Есть еще digest auth, почитайте, это то, что Вы спрашиваете.
FTP — совершенно иной протокол, и там сделано по-другому.

CodeMaster написал:

[q]

Что протокол другой это я понимамба, как сделано - х.з., но почему в HTTP не сделать так же? Такое очучение, что в разработке HTTP не предполагали, что будет нужна аутентификация.

[/q]

Предполагали ещё как.
https://pogugli.com/?331960

CodeMaster написал:

[q]

Но допустим я понял неправильно, тогда вопрос: почему это не используется вместо cookie?

[/q]

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


Тут фишка в чём. Куки позволяют очень гибко всё запоминать. HTTP-аутентификация, как и FTP очень ограничена по функциональности и удобству для пользователя (тупого, не админа с высшим образованием). Потом, у FTP используется единое соединение на всё время работы, а у HTTP делается по соединению на запрос, т.е. каждый раз надо проводить аутентификацию. Вопрос зачем это делать, если можно использовать сессии - гораздо удобнее.

1. В сфере вебдева работает очень много некомпетентных людей. Даже есть такое выражение: «веб-макаки». Поэтому, аутентификация будет реализована средствами того фреймворка, который использует девелопер (который «модный» в текущем полугодии). У него «из коробки» будут работать сессии, масштабирование и т.п. К тому же, от маркетолога+дизайнера придёт требование «сделать форму логина», это привычно пользователю. А настроить веб-сервер, модули аутентификации для него — часто девелоперу вообще не под силу.
2. Без представления, что за сайт, но первый ответ по делу: https://switch-case.ru/72886424. Правда, для новичка ответ понять довольно сложно.
3. Делают то, за что платят деньги. Соответственно, если в спросе условный Angular, потому что его распиарил Гугл, значит будут делать чаще на нём, а не на чём-то ином.
4. Браузерную аутентификацию можно встретить, но не на публичных сайтах. Например, в веб-мордах роутеров встречается. Или в интранетах.

Поэтому, отказ от браузерной аутентификации — это комплекс причин; просто делают как удобнее.

m_emelchenkov написал:

[q]

Поэтому, отказ от браузерной аутентификации — это комплекс причин; просто делают как удобнее.

[/q]

Вот я кагбе про это и спрашивал:

CodeMaster написал:

[q]

Или в принципе могут (не учитывая альтернативы cookie), но не делают потому, что все делают с cookie?

[/q]

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