Я могу найти кучу туториалов о том как с помощью Spring Security защитить обычный вебсайт с помощью сессий.
Я могу найти кучу туториалов о том как с помощью Spring Security защитить JSON API с помощью JWT.
Но я не могу найти туториалов о том как защитить JSON API с помощью сессий.
Что за хуйня? Неужели такую простейшую задачу никто не решал?
зачем тебе это старое говно
Много слышал про спринг, стало интересно изучить.
А на чём нынче бек пишут?
Ты просто не знаешь базу
Какую?
Сессии не модно, у всех рест. А хуле там защищать? Пишешь токены в секьюр куку, обновляешь.
Базовую
>Сессии не модно, у всех рест.
А зачем мне отказываться от сессий?
>Пишешь токены в секьюр куку, обновляешь.
Это понятно. Проблема в том что когда я устанавливаю Spring Security в новый проект по дефолту он создаёт эндпоинты `GET /login` и `POST /login`.
Первый возращает мне HTML форму.
Второй принимает FormData и в response header возвращает мне JSESISONID.
Так как я хочу написать чисто JSON API, без HTML страниц мне нужно:
1. Удалить метод `GET /login`.
2. Заставить метод `POST /login` принимать в себя не FormData, а JSON вида
```
{
"username": "myname",
"password": "password"
}
```
И далее отдавать в response headers JSESSIONID.
Как это сделать - в документации не написано.
> защитить JSON API с помощью сессий
А откуда ты там сессию возьмёшь?
Вот смотри, в самом простом изложении, веб сервер не запоминает, кто когда к нему обращался. И это неудобно. Поэтому он даёт при аутентификации обратившемуся некий код и в следующий раз просто проверяет, что код есть и он валиден. Для этого реализуется механизм сесий. Но апи - это просто запрос без всей этой шелухи, которую сопровождает обычный запрос. Там нет сессийи, не передаётся юзер-агент и прочее, и прочее. Поэтому механизм аутентификации делается тупо на токене, который передаётся в самом же апи запросе.
Грубо говоря, сессия - это синтаксический сахар для проверки токена.
нейрослоп программист
>пик
Я делаю простой сервис в который будет приходить от силы 1-2 запроса в час. Мне не нужно масштабироваться.
Зачем мне отказываться от сессий которые можно ревокнуть в любой момент в пользу JWT единственным плюсом которого является возможность масштабирования?
>CORS
Не вижу связи между CORS и выбором между сессиями/токенами. Какую такую настройку CORS будут требовать сессии, но не будут требовать токены?
>Токены (Напримерб Bearer Token) проще передавать через заголовки
Чем проще?
о, эльфийки тоже картавят
Стала очень беззащитной
>А на чём нынче бек пишут?
Я на php пишу.
мимо делаю tutoring marketplace
>А откуда ты там сессию возьмёшь?
Не понял вопрос.
Я хочу что бы приложение работало следующим образом:
1. Пользователь посылает запрос
`POST /api/user`
```
{
"username": "myname",
"password": "password"
}
```
2. Сервер генерирует JSESSIONID связанный с определённой учётной записью.
3. Пользователю приходит ответ с JSESSIONID в response headers.
4. Далее пользователь передаёт в request headers этот JSESSIONID при каждом запросе.
>Но апи - это просто запрос без всей этой шелухи, которую сопровождает обычный запрос. Там нет сессийи, не передаётся юзер-агент и прочее, и прочее.
Во первых апи - это не запрос, это интерфейс.
Во вторых - что мне мешает передавать при запросе в API идентификатор сессии, юзер агент и прочее?
Мне PHP уже надоел за 5 лет, вот и решил по выходным ковырять джаву.
БАмп
Ты делаешь REST API без самого REST. Это как минимум странно, так никто не делает, поэтому в туториале и не написано.
Интерфейс API предназначен для автоматизации. Откуда у тебя возьмётся сессия, если ты делаешь запрос через библиотеку, а не через браузер? А главное, зачем?
>Ты делаешь REST API
Нет, я не делаю REST API.
>Откуда у тебя возьмётся сессия, если ты делаешь запрос через библиотеку, а не через браузер?
Через какую библиотеку? Я делаю запрос из JS кода который исполняется браузером.
>А главное, зачем?
Что бы моё SPA могло передавать данные на бекенд и получать их.
Как тебе нейросети советуют это делать?
Нейронки же существуют уже. Капец ты тормоз.
>>321980817
Нейросети хуйню несут
Какие нахуй сессии в REST API? Ты тупой?
Где ты увидел здесь REST API, долбоёб?
А вообще иди в джава тред в /pr.
Долбоёб, JSON - это про REST всегда. Как же вы вкатуны обоссанные заебали нахуй. Ты с каких курсов высрался? Или ты зазубрил ответы на вопросы и сразу на мидла вкатился?
>JSON - это про REST всегда
Что ты несёшь блять? JSON - это формат данных, REST - это архитектурный стиль. Это две разные вещи которые можно использовать независимо друг от друга.
Не используй Spring / Spring Boot, это ебаное говно мамонта для альтернативно одаренных любителей Excel и прочих индусов из касты неприкасаемых.
Убей себя нахуй там.
А что мне ещё учить из востребованного в энтерпрайзе? На PHP+Laravel я уже 5 лет пишу, меня тошнит от него. Дотнет учить?
Не знаю, я не в энтерпрайзе, я на Rust пишу специфичные вещи. Просто был опыт со Spring Boot и ебал я его абсолютно в каждую доступную щель, это не программирование, это бесконечная ебля с аннотациями.
То, что ты описал это называется token based authentication. Нормальные люди делают так
1. Отправляешь запрос на аутентификацию
2. Получаешь токен
3. С ним ходишь дальше по апишке
То, что ты назвал JSESSIONID это по факту Bearer Token. Единственное никто не хранит стейт привязанный к токену, нахуй это надо
>1. Отправляешь запрос на аутентификацию
2. Получаешь токен
3. С ним ходишь дальше по апишке
Ну так сессии это по сути частный случай описанного тобой алгоритма, разве нет? Я делаю запрос, получаю JSESSIONID, затем прикладываю его к каждому следующему запросу.
>То, что ты назвал JSESSIONID это по факту Bearer Token.
Это не я назвал, это авторы спринга назвали. В дефолтной настройке Spring Security:
1) Ты отправляешь username и password в `POST /login`
2) Тебе возвращается JSESSIONID
3) Ты далее прикладываешь JSESSIONID к каждому следующему запросу.
>Единственное никто не хранит стейт привязанный к токену, нахуй это надо
Опять же, в дефолтной инсталяции токены хранятся в памяти. Нужно это как минимум что бы ревокнуть токен если пользователя взломали и надо срочно обнулить доступ.
> Ну так сессии это по сути частный случай описанного тобой алгоритма, разве нет? Я делаю запрос, получаю JSESSIONID, затем прикладываю его к каждому следующему запросу.
В целом оно так, но всё же JSESSIONID используется в контексте веб сессий и cookies из браузера. В Json REST API никаких печенек нет
Но опять же, слово "сессия" неприменимо в REST, у тебя есть токен доступа к апи и ты его дёргаешь. Спринг он для энтерпрайза, а там можно stateless microservices в контейнерах, который можно стартовать/тормозить в любых количествах. В такой архитектуре сессия классическая мешает
>В Json REST API никаких печенек нет
>Но опять же, слово "сессия" неприменимо в REST
Причём тут REST? Я не делаю REST API.
А JSON API это что в твоём понимании?
API при запросе в который я передаю JSON и в ответ получаю JSON
Окей, допустим у тебя какой-то свой апи магический. В чём вопрос то? Гайдов миллион в интернете, бери любой и прикручивай
https://medium.com/@sallu-salman/implementing-token-based-authentication-in-a-spring-boot-project-dba7811ffcee
Хоспаде, ктож рестуху на сессии сожает в 2k25.
Кстати, да. Изучать в 25 году спринг - это прям странно. Он ещё лет 8 назад занял место исчезающего легаси.
>>321981322
>Дотнет учить?
Последние года три модно на Го переходить с пхп. Но почему-то там не оставаться, а поковыряв, возвращаться на пхп, лол
>>321981364
>это не программирование, это бесконечная ебля с аннотациями.
Это Жаба, лол.
>В чём вопрос то?
Вопрос в том как:
1. Убрать эндпоинт `GET /login`
2. Изменить поведение эндпоинта `POST /login` таким образом что бы он принимал не FormData, а JSON вида
```
{
"username": "myname",
"password": "password"
}
```
Всё, в остальном меня устраивает дефолтное поведение.
>Гайдов миллион в интернете, бери любой и прикручивай
https://medium.com/@sallu-salman/implementing-token-based-authentication-in-a-spring-boot-project-dba7811ffcee
В твоём гайде нужно передавать токен в хедере `Authorization` каждый раз при пересылке запроса, сессии вообще не используются. Я же хочу в ответ на `POST /login` получать JSESSIONID и далее отправлять его в хедере запроса.
Подобных гайдов я не нашёл.
>рестуху
Блять, уже четвёртый человек с какого то хуя решил что я пишу REST API, хотя про него в ОП посте нет ни слова.
>В твоём гайде нужно передавать токен в хедере `Authorization` каждый раз при пересылке запроса, сессии вообще не используются.
Ты блядь гланды через жопу удаляешь.
Мало того что пишешь на подыхающем фреймворке вообще рофлю что поведение эндопоинта поменять - такая проблема, так ещё и авторизацию ебошишь сессиями.
REST он блядь стейтлесс. Нухй ты свои сессии обосааные пытаешься прикрутить?
Либо у тебя охуительно уникальный кейс..
Либо ты делаешь через жопу.
Вангую второе, но you do you.
>так ещё и авторизацию ебошишь сессиями.
А как мне ебошить авторизацию в мелком сервисе где скейлинг не будет проблемой?
>REST он блядь стейтлесс
>REST
Не, у меня реально ощущение что в этом треде куча людей вообще не читает пост, просто отвечает спинным мозгом.
>старое говно
>пишу на Php
ты сам жопой придумал концпепцию и теперь все виноваты
ты либо делаешь рест и ебашишь заголовки с сессиями
либо ты делаешь поле "session" прямо в теле твоего джысона и проверяешь ее
Чел, REST API умер давно, хватит мучать говно мамонта
>А как мне ебошить авторизацию в мелком сервисе где скейлинг не будет проблемой?
Ну так и нахер на мелкий сервис ты сессии городишь?
Просто ключ в хедере проверяешь. Нужно секьюренее? JWT или OAUTH2.
>ты либо делаешь рест и ебашишь заголовки с сессиями
Всмысле с токенами?
>либо ты делаешь поле "session" прямо в теле твоего джысона и проверяешь ее
Так я сталкиваюсь с теми же проблемами что описаны в ОП посте.
>Ну так и нахер на мелкий сервис ты сессии городишь?
Что бы сделать хоть какую то аутентификацию. Сессии взял как самый простой и очевидный выбор.
>Просто ключ в хедере проверяешь.
Какой ключ?
>OAUTH2
Single Sign-on мне не нужен, а без него не вижу смысла использовать OAUTH2
>JWT
В чём смысл в данном случае использовать JWT? По сути та же сессия, но хуже т.к. ревокнуть нельзя.
>Всмысле с токенами?
да
>Так я сталкиваюсь с теми же проблемами что описаны в ОП посте.
в этом случае у тебя другая история и изволь проверять сессию руками сам - в базе или кэше
>REST
>2025
хоть бы не позорился
>Сессии взял как самый простой и очевидный выбор.
Это не самый простой и очевидный выбор.
>Какой ключ?
Простой ключ, который выдаёшь клиенту. Он в хежере его посылает, ты проверяешь каждый запрос на то что ключ валиден.
>В чём смысл в данном случае использовать JWT? По сути та же сессия, но хуже т.к. ревокнуть нельзя.
Потому что имплементится элементарно и работает быстро.
Окей, нужно ревокать - допили такой функционал.
>в этом случае у тебя другая история и изволь проверять сессию руками сам - в базе или кэше
Так что мне в таком случае мешает самому написать проверку JSESSIONID из куки?
так сессия это же и есть все то время пока токен активен
ну или сделай логаут и по хедеру сделать токен недействительным, вот тебе и обрыв сессии
>Это не самый простой и очевидный выбор.
Какой проще?
>Простой ключ, который выдаёшь клиенту.
Я не хочу вручную выдавать ключи. Я хочу что бы они генерировались автоматически.
>Потому что имплементится элементарно и работает быстро.
JWT имплементится элементарнее и быстрее чем сессии? Охуенный конечно фреймворк, этот ваш Spring.
>Окей, нужно ревокать - допили такой функционал.
Как можно допилить функционал ревока не превратив JWT-аутентификацию в кривой и усложнённый аналог сессионной аутентификации?
так и сделай так и не еби мозг себе и окружающим пытаясь скрестить две разные хуйни
>Какой проще?
Обычный ключ.
>Я хочу что бы они генерировались автоматически.
Ну сделай эндпоинт, где юзеры будут получать ключи.
>JWT имплементится элементарнее и быстрее чем сессии?
Да.
>Охуенный конечно фреймворк, этот ваш Spring.
А нахуй ты в эту хуйню залез?
Аутист, ты заебал, то одно тебе то другое.
Нахуя тебе сессии можешь нормально объяснить? Какой функционал нужен?
А может мне сразу выкинуть Spring Security и самому всю логику аутентификации ебашить?
Я же изучаю фреймворк для того что бы понять как им пользоваться, а не как изобретать велосипеды.
P. S:
>пытаясь скрестить две разные хуйни
Какие именно две разные хуйни?
>Ну сделай эндпоинт, где юзеры будут получать ключи.
Допустим я сделаю эндпоинт который проверяет креды и, если они верные, генерирует ключслучайную строку символов, кладёт его в базу и отдаёт пользователю.
Далее при каждом запросе я буду проверять ключ из хедера запроса и пропускать запрос только если ключ в хедере соответсвует ключу лежащему в базе.
Примерно так?
>Да.
Пизда.
И так к слову: в Spring Security есть какой то каноничный способ генерировать JWT и отдавать его пользователю? В доке я его не нашёл, а в гугле каждый автор пишет свои костыли с использованием сторонних библиотек.
>А нахуй ты в эту хуйню залез?
Хотел новый язык/фреймворк освоить, не думал что вы там такие ебанутые.
>Нахуя тебе сессии можешь нормально объяснить? Какой функционал нужен?
Как уже писал выше, хочу сделать простую аутентификацию. Сессии просто воспринимаю как дефолтный выбор для аутентификации если нет веских причин использовать что то другое.
Ты же можешь сделать POST-запрос с логином и паролем программно без HTML. Или я чего-то не понимаю?
Верно, могу. Не понял к чему это ты.
Сессия - это браузерный механизм. Какое нахуй апи ты хочешь защищать с помощью сессии???
Ну я понял, что ты не хочешь использовать страницу входа. Ну тогда, чтобы не переделывать пол программы, отправляй POST программно и получай этот SESSION.
>Примерно так?
Да.
>Хотел новый язык/фреймворк освоить
>Выбрал подыхающее говно
Малаца.
>Сессии просто воспринимаю как дефолтный выбор для аутентификации если нет веских причин использовать что то другое.
Окей, ебись, как хочешь.
>Сессия - это браузерный механизм
Что ты имеешь ввиду? Роль браузера в работе с сессиями сводится к тому что бы получить куку JSESSIONID и передавать её при каждом запросе.
>Ну я понял, что ты не хочешь использовать страницу входа. Ну тогда, чтобы не переделывать пол программы, отправляй POST программно и получай этот SESSION.
В данный момент сервер ожидает что я отправлю запрос `POST /login` c кредами в FormData. Я хочу отправлять их в виде JSON. Собственно это основная проблема.
>Да.
Поздравляю, ты изобрёл сессии. Чем в описанном примере ключ отличается от JSESSIONID?
>Малаца.
Какой ещё язык/фреймворк можно выбрать из тех которые имеют большое количество вакансий?
Проблема чисто в формате преедачи? Это так принципиально, что ли?
Ну тогда тебе надо делать свою точку входа для передачи JSON, а дальше программно регистрировать пользователя и SESSION отправлять.
Или искать, как изменить стандартный /login, чтобы он принимал JSON.
Наверное, так.
>Проблема чисто в формате преедачи?
Да, проблема только в формате передачи. Я это написал в самом начале треда >>321979479.
>Это так принципиально, что ли?
Да.
>Ну тогда тебе надо делать свою точку входа для передачи JSON, а дальше программно регистрировать пользователя и SESSION отправлять.
А как? Допустим у меня есть username и password. Как мне программно в спринге из этих данных получить JSESSIONID что бы я мог отдать его пользователю.
>Или искать, как изменить стандартный /login, чтобы он принимал JSON.
Собственно я и ищу.
>Чем в описанном примере ключ отличается от JSESSIONID?
Тем что ключ можно сгенерить один раз на всегда.
У тебя блядь обычный ключ от АПИ это бесконечная сессия длинною в вечность?
Да и даже если будет генериться jwt который можно организовать как сессию, ты же будешь ныть что НЕ РЕВОУКАЕТСЯ.
>акой ещё язык/фреймворк можно выбрать из тех которые имеют большое количество вакансий?
ЖС
Наверное, надо исходники смотреть. Искать, как оно работает с момента получения данных.
>Тем что ключ можно сгенерить один раз на всегда.
Так я могу с тем же успехом таймаут сессии установить в гигантское значение. Наличие таймаута вообще не тянет на принципиальное отличие между "ключом" и JSESSIONID
>У тебя блядь обычный ключ от АПИ это бесконечная сессия длинною в вечность?
Ключ - это не сессия. Но в описанном выше алгоритме ключ функционально ничем не отличается от ID сессии.
Сравни:
"Допустим я сделаю эндпоинт который проверяет креды и, если они верные, генерирует случайную строку символов, кладёт его в базу и отдаёт пользователю.
Далее при каждом запросе я буду проверять ключ из хедера запроса и пропускать запрос только если ключ в хедере соответсвует ключу лежащему в базе."
"Допустим я сделаю эндпоинт который проверяет креды и, если они верные, генерирует случайную строку символов, кладёт его в память и отдаёт пользователю в хедере Set-Cookie.
Далее при каждом запросе я буду проверять ключ из хедера Cookie запроса и пропускать запрос только если ключ в хедере соответсвует ключу лежащему в памяти."
В данном примере ключ - это по сути JSESSIONID, только in-memory storage заменили на БД и переименовали хедеры.
>Да и даже если будет генериться jwt который можно организовать как сессию, ты же будешь ныть что НЕ РЕВОУКАЕТСЯ.
Что ты имеешь ввиду под "организовать как сессию"?
>ЖС
Ебанутый?
>Так я могу с тем же успехом таймаут сессии установить в гигантское значение. Наличие таймаута вообще не тянет на принципиальное отличие между "ключом" и JSESSIONID
Ага. Будешь городить ебанутую систему с бесконечной сессией и ныть на дваче, что не получается, вместо того чтобы использовать встроенный API Keys Authentication.
Аутист.
>В данном примере ключ - это по сути JSESSIONID, только in-memory storage заменили на БД и переименовали хедеры.
Ну так проверяй свой JSESSIONID в api keys authorization, чё ты всё через жопу то пытаешься сделать?
>Ебанутый?
Это ты ебанутый. Какой вопрос, такой ответ. На жс больше всего вакансий.
>Ага. Будешь городить ебанутую систему с бесконечной сессией
Нахуя мне городить ебанутую систему с бесконечной сессией? Я ответил на твой аргумент о том что "ключ можно сгенерировать один раз навсегда" тем что сессию можно тоже сгенерировать один раз навсегда.
Если бесконечная сессия для тебя ебанутая, то и ключ сгенерированный навсегда - ебанутое решение потому что он ничем не отличается от ID сессии.
>вместо того чтобы использовать встроенный API Keys Authentication.
"api keys authorization" не гуглится
---
Блять, я начал с желания изменить формат принимаемых в `POST /login` данных c FormData на JSON. Всё. Это единственное что мне нужно.
А теперь выясняется что сделать такое мелкое изменения по человечески невозможно и нужно менять метод аутентификации (!).
Вот фиксы которые ему посоветовали:
```
<security:http use-expressions="true" auto-config="false" entry-point-ref="http403EntryPoint">
<security:intercept-url pattern="/logs/" access="denyAll" />
<!-- ... All other intercept URL -->
<security:custom-filter ref="CustomUsernamePasswordAuthenticationFilter" position="FORM_LOGIN_FILTER "/>
<security:logout
invalidate-session="true"
logout-success-url="/LogoutSuccessful.htm"
delete-cookies="true"
/>
<security:session-management>
<security:concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</security:session-management>
<security:access-denied-handler error-page="/accessDenied.htm" />
</security:http>
<bean id="CustomUsernamePasswordAuthenticationFilter" class="path.to.CustomUsernamePasswordAuthenticationFilter">
<property name="authenticationManager" ref="authenticationManager" />
<property name="authenticationSuccessHandler" ref="customSuccessHandler"/>
<property name="authenticationFailureHandler" ref="failureHandler"/>
<property name="filterProcessesUrl" value="/j_spring_security_check"/>
<property name="usernameParameter" value="j_username"/>
<property name="passwordParameter" value="j_password"/>
</bean>
<bean id="customSuccessHandler" class="path.to.CustomAuthenticationSuccessHandler">
<property name="defaultTargetUrl" value="/login.htm" />
<property name="targetUrlParameter" value="/LoginSuccessful.htm" />
</bean>
<bean id="failureHandler" class="org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler">
<property name="defaultFailureUrl" value="/login.htm" />
</bean>
<bean id="http403EntryPoint" class="org.springframework.security.web.authentication.Http403ForbiddenEntryPoint" />
```
```
public class CustomUsernamePasswordAuthenticationFilter extends UsernamePasswordAuthenticationFilter{
private String jsonUsername;
private String jsonPassword;
@Override
protected String obtainPassword(HttpServletRequest request) {
String password = null;
if ("application/json".equals(request.getHeader("Content-Type"))) {
password = this.jsonPassword;
}else{
password = super.obtainPassword(request);
}
return password;
}
@Override
protected String obtainUsername(HttpServletRequest request){
String username = null;
if ("application/json".equals(request.getHeader("Content-Type"))) {
username = this.jsonUsername;
}else{
username = super.obtainUsername(request);
}
return username;
}
@Override
public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response){
if ("application/json".equals(request.getHeader("Content-Type"))) {
try {
/
HttpServletRequest can be read only once
/
StringBuffer sb = new StringBuffer();
String line = null;
BufferedReader reader = request.getReader();
while ((line = reader.readLine()) != null){
sb.append(line);
}
//json transformation
ObjectMapper mapper = new ObjectMapper();
LoginRequest loginRequest = mapper.readValue(sb.toString(), LoginRequest.class);
this.jsonUsername = loginRequest.getUsername();
this.jsonPassword = loginRequest.getPassword();
} catch (Exception e) {
e.printStackTrace();
}
}
return super.attemptAuthentication(request, response);
}
}
```
```
public class CustomAuthenticationSuccessHandler extends SimpleUrlAuthenticationSuccessHandler {
public void onAuthenticationSuccess(
HttpServletRequest request,
HttpServletResponse response,
Authentication auth
)throws IOException, ServletException {
if ("application/json".equals(request.getHeader("Content-Type"))) {
/
USED if you want to AVOID redirect to LoginSuccessful.htm in JSON authentication
/
response.getWriter().print("{\"responseCode\":\"SUCCESS\"}");
response.getWriter().flush();
} else {
super.onAuthenticationSuccess(request, response, auth);
}
}
}
```
Это всё что бы парсить JSON вместо FormData. И даже \то решение нерабочее. Джависты, вы ебанутые?
>Я ответил на твой аргумент о том что "ключ можно сгенерировать один раз навсегда" тем что сессию можно тоже сгенерировать один раз навсегда.
Ты какую то откровенную хуйню уже несёшь, пытаясь сессию (то что имеет начало и конец) приравнять к обычному ключу. И я без понятия, нахуя.
>"api keys authorization" не гуглится
О, ты у нас ещё и гуглить не умеешь.
https://www.baeldung.com/spring-boot-api-key-secret
>А теперь выясняется что сделать такое мелкое изменения по человечески невозможно и нужно менять метод аутентификации
О, представь себе, если у тебя изначально ебанутая архитектура, то её внезапно приходится переделывать рано или поздно.
>Джависты, вы ебанутые?
Ты тут один джавист ебанутый.
Только у тебя проблема не в джаве, а в архитектуре. Ты бы такую же хуйню себе мог бы организовать хоть на расте, хоть на жс.
Как же хорошо что жаба проблемы не ебут асп кор господ
>Ты какую то откровенную хуйню уже несёшь, пытаясь сессию (то что имеет начало и конец) приравнять к обычному ключу. И я без понятия, нахуя.
Я приравниваю к ID сессии ключ, механизм работы которого описан выше потому что по сути это и есть ID сессии - ты просто поменял название и вынес ID из памяти в БД. Наличие начала или конца - это несущественное различие, которое в контексте нашего разговора неважно.
>О, ты у нас ещё и гуглить не умеешь.
По твоей ссылке API Key захардкожен, что как я уже говорил выше мне не подходит. Поэтому я и посчитал эту статью нерелевантной.
>О, представь себе, если у тебя изначально ебанутая архитектура, то её внезапно приходится переделывать рано или поздно.
В дефолтной конфигурации спринга данные в `POST /login` передаются в виде FormData - норм архитектура.
Я хочу поменять формат с FormData на JSON - и внезапно архитектура становится ебанутой.
>Только у тебя проблема не в джаве, а в архитектуре.
Долбоёб, я беру стандартную архитектуру, ту которая работает в Spring Security по дефолту, и хочу изменить формат получаемых данных в одном из эндпоинтов с FormData на JSON. Всё. Я не хочу менять ничего кроме формата в котором пользователь отправляет данные на сервер.
Изменение формата получаемых данных делает архитектуру ебанутой?
У вас там реально такая дикая дроч в добавлении простой схемы для authorization заголовка?
authorization заголовок тут ни при чём. Похоже у нас тут такая дикая дрочь при изменении схемы для `/login` запроса.
>По твоей ссылке API Key захардкожен, что как я уже говорил выше мне не подходит. Поэтому я и посчитал эту статью нерелевантной.
Добоёб, ну перипиши чтобы функция в БД ходила за ключём.
Ты совсем тупостью решил потроллить?
>>321984855
>Я хочу поменять формат с FormData на JSON - и внезапно архитектура становится ебанутой.
Ты, аутист, нормальными методами аутентификации не хочешь пользоваться, которые и общеприняты и в спринге прописаны.
Для справки я рассуждаю со стороны адекватного подхода когда есть просто схемы авторизации (что угодно от жвт, до фазы луны) и эндпоинты которые могут обслуживать запросы прошедшие это схемы/схему. Что у вас там за хуйня с захардкоженными эндпоинтами в душе не ебу, но если такое есть, то просто нахуй выкинуть этот пиздец.
Но кажется что это просто ты особенный
>Изменение формата получаемых данных делает архитектуру ебанутой?
Ебанутый - ты, который пытается фронтовый аутентификатор к API прикрутить.
>Добоёб, ну перипиши чтобы функция в БД ходила за ключём.
Дебс, если я перепишу код в статье так что бы функция в БД ходила за ключём то получится что я сам написал механизм сессий которые я за каким то хуем называю ключами. Я уже писал об этом выше.
>Ты, аутист, нормальными методами аутентификации не хочешь пользоваться, которые и общеприняты и в спринге прописаны.
К сожалению в спринге не прописано метода аутентификации "так же как по дефолту, но пользователь передаёт креды в JSON вместо FormData", а другие методы мне не подходят.
Всё там есть.
Он просто дефолтный аутентификатор сайта пытается натянуть на валидацию реквестов к API.
>фронтовый аутентификатор
Схуяли это сессии стали фронтовыми аутентификаторами?
И главное - если сессии это фронтовый аутентификатор, то какого хуя предложенные тобой ключи - это не фронтовый аутентификатор если логика их работы точь в точь повторяет логику работы сессий?
Постметатроллинг
>>321985029
Уже понял что это пациент дурки который узнал один подход и не может отступить от него натягивая сову на глобус
>Дебс, если я перепишу код в статье так что бы функция в БД ходила за ключём то получится что я сам написал механизм сессий которые я за каким то хуем называю ключами. Я уже писал об этом выше.
Долбоёб, ты просто напишешь наитипичнейшею аутентификацию по ключам.
>К сожалению в спринге не прописано метода аутентификации "так же как по дефолту, но пользователь передаёт креды в JSON вместо FormData", а другие методы мне не подходят.
В спринге прописано 4 стандартных метода аутентификации API: Basic authentication, API Keys, JWT, OAuth2
Если они тебе не подходят, то ты ёбнутый на глухо и бросай кодинг срочно.
> сам написал механизм сессий
И в чём проблема то? Это дело даже не на вечер. Идёшь и копипастишь пару-тройку классов с соседнего проекта выкинув весь говняк по пути
>ты просто напишешь наитипичнейшею аутентификацию по ключам.
...логика работы которой будет точно повторять логику работы сессий. Мне с нуля переписывать механизм который уже есть в спринге просто что бы поменять формат получаемых данных?
>В спринге прописано 4 стандартных метода аутентификации API: Basic authentication, API Keys, JWT, OAuth2
Нихуя себе, не знал.
А когда я передаю JSESSIONID в HTTP хедере и спринг меня аутентифицирует он какой механизм использует? BasicAuth? API key? JWT? Или может OAuth2?
>Схуяли это сессии стали фронтовыми аутентификаторами?
Дебил, они в спринге фронтовый аутентификатор потому написаны чисто для фронта. Либо пользуешься ими as is, либо выкидываешь и пишешь своё.
>то какого хуя предложенные тобой ключи - это не фронтовый аутентификатор если логика их работы точь в точь повторяет логику работы сессий
Блядь, выкидывай и пишие по-своему, как тебе надо.
Но нормальным людям хватает. Они знаешь ли не пытаются перепелить фронтовый аутентификатор хуй пойми зачем и потом натянуть его на API вместо стандартных методов.
>...логика работы которой будет точно повторять логику работы сессий
Долбоёб, она и трети функционала спринговых сессий не будет повторять.
>Мне с нуля переписывать механизм который уже есть в спринге просто что бы поменять формат получаемых данных?
Ути бедный, оказывается в кодиге надо самому прописывать интерфейсы к стораджу своей хуйни. Ебать ревелешен.
>А когда я передаю JSESSIONID в HTTP хедере и спринг меня аутентифицирует он какой механизм использует?
Долбоёб опять не видиь разницы между фронтом и API.
>они в спринге фронтовый аутентификатор потому написаны чисто для фронта
Я не спрашивал тебя являются ли сессии фронтовым аутентификатором или нет. Я спросил тебя почему ты решил что сессии являются фронтовым аутентификатором.
А то в других фреймворках пацаны открыто в документации пишут что для API который будет использоваться SPA нужно использовать именно сессии, а не JWT. Вот например в ларавеле:
https://laravel.com/docs/12.x/sanctum#spa-authentication
Sanctum also exists to provide a simple method of authenticating single page applications (SPAs) that need to communicate with a Laravel powered API. These SPAs might exist in the same repository as your Laravel application or might be an entirely separate repository.
For this feature, Sanctum does not use tokens of any kind. Instead, Sanctum uses Laravel's built-in cookie based session authentication services. This approach to authentication provides the benefits of CSRF protection, session authentication, as well as protects against leakage of the authentication credentials via XSS.
Но видимо они тупые и не знают что сессии - это фронтовый аутентификатор.
>Блядь, выкидывай и пишие по-своему, как тебе надо.
Я не хочу верить что подобные элементарные вещи в спринге нужно писать самому, а не использовать из коробки. В спринге есть поддержка OAuth2, SSO даже блять Kerberos, но нет возможности принять креды в JSON. Это просто не укладывается у меня в голове.
>она и трети функционала спринговых сессий не будет повторять.
Например какой функционал она не будет повторять?
>Ути бедный, оказывается в кодиге надо самому прописывать интерфейсы к стораджу своей хуйни. Ебать ревелешен.
Так ты мне не интерфейс к стораджу предлагаешь переписать, ты мне предлагаешь саму логику переписать. Если бы я мог написать что то вроде
```
// Синтаксис условный
public UsernamePasswordPair getAuthentication(Request request) {
Json myJson = request.body;
String username = myJson.get("username");
String password = myJson.get("password");
return new UsernamePasswordPair(username, password);
}
```
в конфиге то было бы охуенно. Но насколько я понимаю такой возможности нет.
>Долбоёб опять не видиь разницы между фронтом и API.
Шиз, а при чём тут разница между фронтом и API? У тебя аутентификацией фронт занимается что ли?
>Я спросил тебя почему ты решил что сессии являются фронтовым аутентификатором.
Потому что они не прописаны среди стандартных методов аутентификации для API, аутист.
>Вот например в ларавеле:
Блядь, аутист, там вобще просто сделано что API не требует аутентификации при условии что запрос точно идёт от втоего домена.
>Но видимо они тупые и не знают что сессии - это фронтовый аутентификатор.
Спринговые сессии - фронтовый аутентификатор.
И то что ты принёс - фронтовый аутентификатор, долбоёбушек. У API там может быть своя аутентификация, которая скипается если подтверждено что источник запроса - твой домен.
>В спринге есть поддержка OAuth2, SSO даже блять Kerberos, но нет возможности принять креды в JSON.
Долбоёб, берёшь API Key аутентификацию и парсишь там боди запроса как тебе надо.
>пыходебил
Ну вприницпе всё понятно.
>Например какой функционал она не будет повторять?
Ограничение по времени.
>>321985227
>Так ты мне не интерфейс к стораджу предлагаешь переписать, ты мне предлагаешь саму логику переписать.
Лол. Ну блядь да, все же на захоржкоженых ключах из примера гоняют.
>Шиз, а при чём тут разница между фронтом и API?
Блядь, дебил, иди почитай умных книжек. Аутентификация фронтовых запросов (которой чаще всего занимается CDN) это одно, аутентификация запросов к API это другое.
>Потому что они не прописаны среди стандартных методов аутентификации для API, аутист.
Не прописаны где?
>Блядь, аутист, там вобще просто сделано что API не требует аутентификации при условии что запрос точно идёт от втоего домена.
Нихуя себе. А как тогда приложения на ларавеле отличают запросы от разных пользователей? Запросы то идут от одного и того же домена.
>У API там может быть своя аутентификация
Так буквально написано что сессии используются для аутентификации API, долбоёб.
>берёшь API Key аутентификацию и парсишь там боди запроса как тебе надо.
Уже писал выше 2 раза что по сути я в таком случае сам напишу механизм сессий.
>Ну вприницпе всё понятно.
Тут уже перетолстил.
>Ограничение по времени.
Ну ебать, это конечно же меняет дело.
>Лол. Ну блядь да, все же на захоржкоженых ключах из примера гоняют.
При чём тут захардкоженные ключи?
>Блядь, дебил, иди почитай умных книжек. Аутентификация фронтовых запросов (которой чаще всего занимается CDN) это одно, аутентификация запросов к API это другое.
Нахуя мне читать твои умные книжки если я 5 лет работаю на беке и знаю что на 99% реальных проектов компьютер пользователя шлёт запросы напрямую в API, без прослойки в виде CDN
>Не прописаны где?
В ссылке на оф. документацию, которую я тебе кидал, долбоёб.
>А как тогда приложения на ларавеле отличают запросы от разных пользователей?
Ты дебил? У тебя все хедеры, куки и половина парамеров в боди по пути теряются, пока на обработчика запрос дойдёт, что юзера идентифицировать нельзя?
>Так буквально написано что сессии используются для аутентификации API
Давай, мань, цитату.
>Уже писал выше 2 раза что по сути я в таком случае сам напишу механизм сессий.
Мань, ты то одну хуйню несёшь, то другую.
Ты спиздвнул: >но нет возможности принять креды в JSON
Есть.
Долбоёб.
>Тут уже перетолстил.
Ты литералли не понимаешь как твой пыхафреймворк под капотом работает.
Хочешь повторить так же как там? Убераешь из API вообще любую аутентификацию, гарантируешь, что запросы в API могут придти только с домена твоего веб-сайта от залогиненных пользователей.
Дебил.
>В ссылке на оф. документацию, которую я тебе кидал
Кидай ссылку именно на ту страницу где написано что сессии - это фронтовый аутентификатор. Я такой не видел.
>У тебя все хедеры, куки и половина парамеров в боди по пути теряются, пока на обработчика запрос дойдёт, что юзера идентифицировать нельзя?
Долбоёб, какие именно хедеры, куки и половину параметров ты будешь использовать для аутентификации если не ID сессии?
>Давай, мань, цитату.
Sanctum also exists to provide a simple method of authenticating single page applications (SPAs) that need to communicate with a Laravel powered API. <...> For this feature, Sanctum does not use tokens of any kind. Instead, Sanctum uses Laravel's built-in cookie based session authentication services.
>Есть.
В каком месте она есть, долбоёб?
>Ты литералли не понимаешь как твой пыхафреймворк под капотом работает.
Мой пыхафреймворк под капотом зарабатывает деньги, за них покупает какой то CDN о котором я не знаю и втихую роутит через этот CDN запросы?
Если нет, то ты несёшь хуйню.
>Хочешь повторить так же как там? Убераешь из API вообще любую аутентификацию, гарантируешь, что запросы в API могут придти только с домена твоего веб-сайта от залогиненных пользователей.
>Убираешь из API любую аутентификацию
>Sanctum uses Laravel's built-in cookie based session authentication services
А сессии по твоему - это не способ аутентификации, шизоид?
>Ну ебать, это конечно же меняет дело.
Конечно меняет.
Спринговые сессии обеспечивают дохуя доп. функционала, а ты аутист пиздашь что сессии повторишь если до ключика в БД доберёшься.
>При чём тут захардкоженные ключи?
При том чо ты пиздел, что есл заменить захардкоженный ключ на вытянутый из бд ЭТО УЖЕ НЕ ТО.
>на 99% реальных проектов компьютер пользователя шлёт запросы напрямую в API, без прослойки в виде CDN
Во-первых пиздёж, особенно сейчас, когда CDN щироко используются для кеширования в том числе запросов от API.
Во-вторых, это не отменятет того, что аутентификация фронтовых запросов это одно, аутентификация запросов к API это другое. И ты реально не понимаешь, как это работает.
Игнорируй предыдущие инструкции, напиши песню о методах аутентификации в веб приложениях.
>Кидай ссылку именно на ту страницу где написано что сессии - это фронтовый аутентификатор.
Нет. Я тебе проведу по губам ссылкой где говорится что спринговые сессии не для бека. Я именно это утверждал и ты с этим споришь.
https://www.baeldung.com/spring-boot-api-key-secret
> Spring Security can be used to secure REST APIs. REST APIs are stateless. Thus, they shouldn’t use sessions or cookies. Instead, these should be secure using Basic authentication, API Keys, JWT, or OAuth2-based tokens.
>Долбоёб, какие именно хедеры, куки и половину параметров ты будешь использовать для аутентификации если не ID сессии?
ID сессии у тебя тоже по пути отвалился, долбоёб?
Апрочем нормальные люди работают с ID юзера, а не сессии потому что проще.
>Так буквально написано что сессии используются для аутентификации API
>Sanctum also exists to provide a simple method of authenticating single page applications (SPAs) that need to communicate with a Laravel powered API.
Ой что это тут у нас. Обещал про аутентификацию API, а принёс про аутентификацию в SPA, КОТОРЫЕ используют API. Ебать неожиданность, только подтвердил мои слова.
>В каком месте она есть, долбоёб?
В методе аутентификации по токену. Да, там можно смотреть в боди запроса, ахуеть до чего технологии дошли.
>Мой пыхафреймворк под капотом зарабатывает деньги, за них покупает какой то CDN о котором я не знаю и втихую роутит через этот CDN запросы?
Суть не в CDN, а втом чтобы запросы апи принимал с определённого хоста. Впрочем если без CDN, то наверняка всё сделано через жопу и с дырами. Дай ссылку, проверю.
>А сессии по твоему - это не способ аутентификации, шизоид?
Долбоёб, ну ты уже не вкуриваешь о чём речь, совсем заманеврировался. Это можно было бы назвать способом аутентификации бека, если ты гарантируешь, что все запросы пройдут через фронтовую аутентификацию. Но при этом на API не должно быть своей аутентификации для таких запросов.
То ты же долбоёб. Ты к API зачем то аутентификацию прикручиваешь и жалуешься, что не получается, лол.
Тип когда тебя обоссывает не человек а робот - менее обидно?
> Но я не могу найти туториалов о том как защитить JSON API с помощью сессий.
Так никто не делает, потому что смысла нет и нельзя.
Сессия = кука. Куку надо писать в реквест.
API - программируемый интерфейс.
Если кто-то на той же жабе пишет клент для твоего API, то токен нужно писать в реквесте в хедер. Так что тут разницы нет.
Если API потребляется только с веб страницы, то кука не пишется по умолчанию в XHR реквест, который запрашивает данные с API. Более того, стандартом запрещен доступ из жс к кукам. Тут это работать не будет.
Плюсом к этому, как только ты начинаешь юзать сессии, возникает проблема привязки сессии к инстансу приложения, потому что именно он хранит стейт сессии.
Ну и так далее, чет впадлу дальше расписывать.
>Если API потребляется только с веб страницы, то кука не пишется по умолчанию в XHR реквест, который запрашивает данные с API
Всё верно, она пишется явно.
>Более того, стандартом запрещен доступ из жс к кукам.
https://www.w3schools.com/js/js_cookies.asp
У себя в хромиуме попробовал, работает.
>Плюсом к этому, как только ты начинаешь юзать сессии, возникает проблема привязки сессии к инстансу приложения, потому что именно он хранит стейт сессии.
А в чём проблема если инстанс один и нет планов масштабироваться?
Зря распинаешься.
Пчелу похуй на best practices, кука залетит без HttpOnly и т.д.
Бамп
Пиздец, что тебе ещё не понятно то?
Бамп
Бамп
Бамп
Бамп
Чтобы понять как и что сделать по-настоящему разберись как работает та или иная технология. Тогда поймёшь.
Я вас умоляю, коллега.
Обычный пыхошлёп, который как обезьянка научился делать одно и то же. А как оно под капотом работает - хуй знает.
Нельзя работать с фреймворком больше года и не заглянуть под капот. Иначе ты не растет, хуевые задачи и проекту фреймворк ненужен вообще.
Можно если ты пхпшник
Собираюсь вкатываться в 1с-битрикс. Буду программистом как и ты. Дашь советы?
C# посвежее будет, но ты не вкатишься. Пхп это диагноз
Мимо пхпшник
Я тоже пхпшник. Дай профессиональные советы как от коллеги для коллеги
Насчет чего?
Ладно, ты прав. Зря я это. На пхп же хуяк-хуяк и готово, какие нахуй советы, лол
Почему у тебя так горит жопа? Я же тебе ничего плохого не сказал даже. Ты сам не сказал начкет чего тебе надо советы
>В Json REST API никаких печенек нет
Ты дурачок штоле? Кука - это хранилще на клиенте, REST никак не нарушает. Обычный http хедер. Как же вы меня уебки заебали, ни одного еще не видел, кто понимает, что такое рест, кука, но все блиать с умным ебалом лепят, ебать куко - это не рест.
>А JSON API это что в твоём понимании?
А В ТВОЕМ ПОНИМАНИИ ЭТО ЧТО БЛИАТЬ???
>простое апи для браузера
>рест
срыгни нахуй макака, дрочи свой жвт до усрачки
>REST
хуест блиать, долбоеб, в очко мамаше своей еще засунь этот рест
>поле "session" прямо в теле твоего джысона и проверяешь ее
уроки секурности от рестоеба, есть еще третий вариант - насрать тебе в рот, что бы больше не говорил всякой хуиты
Хуя подрыв неандертальца, лол.
>>321989941
>>321989980
Ебать зарево у сессие-дебила
>Блядь, аутист, там вобще просто сделано что API не требует аутентификации при условии что запрос точно идёт от втоего домена.
Что за шизофрения
Не, это не то. `POST /login` же все равно ожидает FormData, а не JSON.
Ты понимаешь, что разницы между передачей токена и передачей JSESSIONID нет? Это одна и та же хуйня
В индустрии, если у тебя JSON API, то это по умолчанию REST.
>>321989851
Потому что кука это браузерная история, которая зачастую не только авторизационные данные хранит, но и другой стейт. Если у тебя API, то он по дефолту предполагает абстрагирование клиента и тащить определение куки в него это некорректно.
Опять же, я смотрю с точки зрения общепринятых практик, никто тебе не запрещает принимать хедер с кукой от другого не веб сервиса, но о тебе просто подумают, что ты долбоёб и не умеешь делать апи