@ldefix: nie uzywalem oauth2 przez 3rd party, ale wydaje mi sie ze obiekt autoryzacji idzie przez jakis UserDetailService albo UserDetailsMapper, a jak nie przez zaden z nich to na 100% przechodzi przez AuthorititesPopulator, te klasy mozesz zaimplementowac po swojemu i wstrzyknac do AuthenticationManagerBuilder w klasie extendujacej WebSecurityConfigurerAdapter. Tam powinienes miec wszystko na dloni jak odpalisz debugger. Jeszcze paczke org.sprinframework.security dalbym na debug.

czy email jest w bazie.

@ldefix: to bym przesniol do wlasnego UserDetailService

@elektroencefalograf: oczywiście że singletonem ( ͡° ͜ʖ ͡°)

Pokaż spoiler

@interface Dziękuję, panie uszczypliwy

@kornfan: tak na oko to w Twoim przypadku wystarczyłoby wysłać jsona z samymi id. Na podstawie tych id pobierasz screening, set, reservation i je sobie sklejasz w jeden obiekt już w jakimś serwisie. Druga opcja - hateoas i hal

@kornfan: jeśli wysyłasz same id, to sobie pobierz odpowiednie encje poprzez odpowiednie repozytoria na podstawie tych id i sklej ostateczny obiekt, wiadomo, że na podstawie samych id nie stanie się magia. Tak jak wspomniałem zobacz na hateos i format hal wykorzystywany choćby przez spring data rest, wtedy wysyłasz jsona typu:
{
"id": null,
"screening": "http://costam/api/screenings/1",Pokaż całość

@Arima: w tych korpo na pewno: Accenture, Signity, Altkom, Asseco

@Arima: z ciekawości - zawołaj jak czegoś się dowiesz

@t12t12: Ja zasugerowałbym coś podobnego jak @sosna119 . W bazie trzymasz timestamp ostatniego "heartbeata" info czy jest edytowany czy nie.

Aplikacja, która uzyskała dostęp i edytuje wysyła co X czasu "hearbeat", że jeszcze edytuje.

Serwer, kiedy przychodzi rządanie o edycję, przyznaje dostęp jeśli dokument nie jest edytowany (info w bazie, że nie jest), lub hearbeat nie przyszedł w odpowiednim czasie (np.Pokaż całość

Jak korzystasz z websocketów to możesz od tego uzależnić, czy dany użytkownik edytuje dokument. Jak mu zerwie połączenie to znak, że pewnie przestał edytować.

@stash: Nieprawda to jest :) Aplikacje webowe nie powinny opierać się na stabilności łącza. Przecież możesz z tego korzystać w telefonie albo w pociągu na słabym połączeniu. Zanik może być tymczasowy i do tego czasu aplikacja powinna przechowywać dane lokalnie, żeby wysłać je do serwera jakPokaż całość