ну если абстрактно

если допустим нужен был аудит действия

приходилось отдавать id пользователя

на сервер

с клиента

только у нас клиент это не js ?

это полноценный java сервер

который общался с другими java приложухами по сети

а если допустим такой кейс

front + node js

back + jetty/tomcat

вот как тут с сессией быть?

ну я хз, я расказал про наш случай

когда java + java была

да, я твой случай понял

он очень похож на тот, с которым я работаю

тоже джава + джава

а вообще сессию можно укладывать в редис какой нить

на одном проекте, когда клиент был реплецирован - так и делали

сессия лежала в редисе

а спринг брал оттуда её

слушай, а как тогда делают фронт на одном сервере, бэк на другом?

Основная страничка идет с бэка)

Оттудва грузится фронт

Основная страничка идет с бэка)

лол, я так делал)

индекс шел с джетти

все остальное энджинкс отдавал

Территориально он может быть где угодно)

причем индекс был шаблоном, на котором строилось

а вот интересно было бы кейс посмотреть

Иначе спрингу секурити придет привет тупо)

front + nodejs, back+jetty

А почему у тебя в первом случае nodejs, во втором jetty

Я чего то не знаю или не понимаю

ну вроде модно сейчас так делать

фронт крутится на легковесном сервере

чистый клиент

и на сервере вообще нет джавы

только JS

Ну я к тому что потенциально на беке может быть что угодно

В чем разница?

на бэке да, на выбор команды

конкретно интересовало, чтобы физически с разных серверов это было

и для фронта node.js

Ну меня именно это смутило

по идее можно же через Oauth2 провернуть

По идее фронт должен статикой через нгикс отдаваться

как-то клиенты же пишут на чистом джаваскрипте с авторизацией

Ммм. Только если у тебя есть проверки на бэкенде.

Ну зачем же

Можно просто организовать туннель между серверами

И с других не обрабатывать запросы

как-то клиенты же пишут на чистом джаваскрипте с авторизацией

Через бесик можно через oauth

Но это тупо

короче, просто хотелось бы жестко разграничить фронт и бэк. Клиент на отдельном сервере без джавы, и бэк

Хотя бы на уровне базы. Вроде у ПГ была фича, которая позволяла юзеров базы использовать во фронтенде

клиент авторизуется в бэке - юзаем

Ну так так и работает

Ну зачем же

Потому что любой паблик жс код может быть изменен или выполнен руками. Это относится и к рест апи.

Поэтому нельзя просто взять и доверять "своему" жс коду

нашел

https://spring.io/blog/2015/02/03/sso-with-oauth2-angular-js-and-spring-security-part-v

правда тут у клиента джавовский сервер и какая-то логика

Нахрена oauth использовать для такой ерунды?

но в целом очень близко к микросервисной философии с API Gateway

Нахрена oauth использовать для такой ерунды?

для какой?

для nodejs

Ну я как понимаю тебеж обычный фронт надо авторизовывать

ERROR: S client not available

да

но фронт на отдельном серваке

сессия жеж потеряется

А oauth для распред авторизации клиентов создан

ты сам сказал

Это как из пушки по воробьям

Я сказал что можно)) но не нужно)

я не хочу отдавать фронт с того же сервера, где и апи

а простой секьюрити такое не приемлет

поэтому оауз2 не такой плохой вариант

ну либо я чего-то не понимаю

Вот если у тебя есть например мобильное приложения(куча от разных провайдеров) эмбдед скрипт через крос работающий с твоим тогда да oauth в тему

Паш, давай тогда такой вопрос

как мне авторизовать приложение с другого сервера стандартным секьюрити?

Тебе надо сделать так)

слушаю и внимаю

Пихнуть фронт на один сервер, бэк на другой

Перед ними поставить нгикс

Через него гнать трафик с одного домена

В бэке создать индекс в который вставить скрипт апп.жс

Все)

это я уже делал)

В бэке создать индекс в который вставить скрипт апп.жс

Все)

а без этого только оауз2 варик?

правильно я понимаю тебя?

Так так как ты делал стандартный паттерн для этого)) я не понимаю в чем проблема)

я тебя понимаю, но вот хочу без этого)

оауз2?

а без этого только оауз2 варик?

Можно по идее бэсик еще и то если это будет с одрого домена

Но надо будет клиент на фронте по сути держать

ты имеешь в виду базу юзеров и логику?