Жесть. Возьмите хотя бы Keycloak by RedHat. Это сертифицированное решение. Будет вам и OAuth, и JWT и интеграция со Spring Security из коробки, просто при помощи стартера Spring Boot.
Да и в методах обработки endpoint'а все равно, наверное, придется доставать юзера из контекста. Возможно я не прав, так как не сильно в нем разбирался, но статья в любом случае не об этом. (...) Мне нужно было что-то простое и удобное в использовании. Пришла идея сделать это через аннотацию.
Эта замечательная идея не только вам пришла в голову.
Spring Security предоставляет @PreAuthorize, @PreFilter, @PostAuthorize и @PostFilter, внутри которых можно писать SpEL, и вызывать стандартные и кастомные методы проверки доступа.
"Доставать юзера из контекста" очень просто. Объект Authentication со всей информацией о юзере и его грантах доступен вас из любого места приложения, через публичный статический метод контекста. И всё это полностью поддерживается в юнит и интеграционных тестах.
Согласен, вы правы. Но это нормально что языки постоянно изменяются и развиваются. Меняется мир, границы государств, меняются носители этих языков. Ничто не стоит на месте.
На самом деле, похоже что в английском что-то пошло не так. Судите сами:
To clarify — clarification, to notify — notification, to simplify — simplification, to verify — verification, to justify — justification и так далее. Во французском эти же слова образуются точно так же. И во французском есть authentifier — authentification.
Но глагол "аутентифицировать" в английском почему то получится другим: to authenticate. И отсюда authentication без "фи". Но сказать authentification не будет большой ошибкой, и в словаре это слово есть. Как если бы существовал глагол "to authentify".
Очень просто. В глаголе "authentifier" имеется "fi". Он означает "certifier l'authenticité" (устанавливать подлинность). От того самого слова "authentique" (lat. authenticus, grec authentikos). Такое уж во французском языке словообразование.
Несколько примеров (парами французский/английский варианты):
… и так далее, можно таких примеров найти очень много.
В английском слова образуются немного по другому, поэтому там этих "фи" нет.
Я не лингвист, если что. Специалист объяснил бы лучше. Но мне кажется это вполне логичным. Может быть просто потому что ухо привыкло. Я живу в городе где большинство людей одинаково хорошо говорят на обоих языках.
Вы правы, транскрипция фамилии /soʊl/, однако в русском разделе Википедии эта страница отсутствует. Непонятно что вы имеете в виду.
Вообще, в американском английском иногда вместо "о" произносят "а". Или, например, проглатывают "т". Есть и другие приколы. Фамилия "Путин" произносится как "Пу'н" (там в середине есть некий неописуемый придыхательный звук), а "водка" звучит больше похоже на "вадка". Может быть любители вадки и искаверкали фамилию уважаемого экономиста?
А вы приезжайте в Канаду, тут за детей наоборот нехило доплачивает правительство, и медицина бесплатная, школы/садики тоже. Я бы в Штаты ни за что не уехал отсюда, хотя приглашают каждый день.
Сортировка по суррогатному ключу это какой-то очень специфический случай. По крайней мере в моей практике за два десятилетия это встречалось буквально пару раз.
Чаще всего юзеры имеют возможность выбирать поля для (мульти-)сортировки и налагать сколько угодно фильтров. Так что да, придётся таки сканировать всё и потом возвращать кусочек.
Добавьте тег "MySQL", пожалуйста. Все СУБД устроены по своему, и поэтому полезный совет для одной из них чаще всего окажется вредным для другой.
На самом деле я сморозил глупость. В селектах построчно счётчик так просто не наматывается. Всё немного сложнее, он наматывается внутри хранимых процедур.
Так что теперь точно придётся написать статью с примерами и переводом комментов в коде, чтоб загладить вину :-)
Кстати, Кирилл, можете добавить в вашу статью ещё один способ накрутки счётчика транзакций, о котором мало кто из разработчиков знает.
В PL/pgSQL обработка исключений реализуется при помощи SAVEPOINT. Если в хранимой процедуре/функции имеется блок "EXCEPTION", то при каждом выполнении этого кода будет создаваться SAVEPOINT, и соответственно, будет увеличиваться счётчик транзакций. Если такая функция применяется к возвращаемым строкам запроса, то это может приводить к аварийной остановке кластера, я читал про такие кейсы.
Об этом не сказано в документации, но есть подробный комментарий в исходном коде.
Отсюда вытекает рекомендация. Не используйте обработчики исключений внутри функций, которые вы собираетесь применять к строкам, возвращаемых запросами. Этот механизм предназначен для процедур, реализующих бизнес логику на стороне СУБД,
Небольшой лайф хак.
Если вы очкарик, как и я, то просто закажите очки на пол-диоптрии послабее. Я так и сделал. Картинка просто отличная, супер сглаженные шрифты, даже на ЭЛТ мониторах. Я не шучу :)
Lombok это препроцессор аннотаций, который, будучи в classpath, автоматически распознается и используется Java компилятором (javac). Ничего в рантайм при этом не привносится. Погуглите интерфейс "javax.annotation.processing.Processor"
Lombok это моя любовь, но даже с его волшебными аннотациями мне хочется большего. Потому я создаю свои аннотации, использую AOP, автоконфигурации и прочую черную магию. Я хочу дакларативного программирования. Очень сложный ядровой код, который спрятан внутри библиотек и инфраструктурных хранимых процедур БД, который правят синьёры-помидоры, и очень простой бизнес код, который с лёгкостью правят новички, следуя простым правилам. Желающие разобраться как всё работает тоже со временем становятся синьёрами.
Вы, конечно же, правы. Я и не спорю с вами, на самом деле. Мне всего лишь не понравились категоричные заявления в стиле Чеховского соседа "этого не может быть, потому что этого не может быть никогда", и я решил высказать альтернативную точку зрения, хотя я знал заранее что в меня полетят помидоры. Мне просто было интересно побеседовать на эту тему.
Я знаю современные официальные рекоменадции, и всю аргументацию, за ними стоящую, и я регулярно смотрю выступления Juergen Hoeller, слушаю Bootiful Podcast by Josh Long и прочих мейнтейнеров этого замечательного фреймворка. Но всё же предпочитаю работать так, как я описал, и этот подход полностью поддерживается и оправдывает себя с годами. И тот же Джош Лонг в своих видео не парится и делает ровно то же самое. На все ваши аргументы я могу привести контраргументы и наоборот.
Мне, кажется, особо нечего добавить к тому, что я написал вам и другим участникам дискусии. Спасибо разработчикам Spring и экосистемы вокруг него за то, что мы, такие разные, можем использовать разные подходы. И спасибо вам за интересную беседу :-)
Вы не поняли, я как раз хочу видеть эти аннотации. Они подчёркивают что это не просто какие-то приватные поля, а именно внешние зависимости, жизненный цикл которых контролируется контейнером. Я открываю код сразу вижу что и как.
Lombok я тоже использую повсеместно, уже много лет, всё что в нем есть.
Для обычных классов (не бинов) я использую конструкторы. Для инфраструктурных бинов, которые создаются автоконгурациями Spring Boot я тоже делаю конструктор. Это совсем другое дело. Таких бинов мало и они очень сложные.
Но для всего остального, обычных сервисных классов, реализующих бизнес логику, я принципиально использую аннотации на приватных полях для наглядности.
Вас не беспокоит что у вас нет конструктора для JpaRepository? Ну вот точно также мне пофигу и на конструкторы для прочих "рядовых" бинов. Мне так нравится, и не вызывает никаких неудобств.
Странно что чувак не выкинул весь Spring. Всё стальное показалось простым? :)
Жесть. Возьмите хотя бы Keycloak by RedHat. Это сертифицированное решение. Будет вам и OAuth, и JWT и интеграция со Spring Security из коробки, просто при помощи стартера Spring Boot.
Эта замечательная идея не только вам пришла в голову.
Spring Security предоставляет @PreAuthorize, @PreFilter, @PostAuthorize и @PostFilter, внутри которых можно писать SpEL, и вызывать стандартные и кастомные методы проверки доступа.
"Доставать юзера из контекста" очень просто. Объект Authentication со всей информацией о юзере и его грантах доступен вас из любого места приложения, через публичный статический метод контекста. И всё это полностью поддерживается в юнит и интеграционных тестах.
Да, было дело, публиковал что-то лет 10 назад. Спасибо за попытку и за информацию. Теперь придётся довести до ума пару вещей из черновиков :)
Согласен, вы правы. Но это нормально что языки постоянно изменяются и развиваются. Меняется мир, границы государств, меняются носители этих языков. Ничто не стоит на месте.
На самом деле, похоже что в английском что-то пошло не так. Судите сами:
To clarify — clarification, to notify — notification, to simplify — simplification, to verify — verification, to justify — justification и так далее. Во французском эти же слова образуются точно так же. И во французском есть authentifier — authentification.
Но глагол "аутентифицировать" в английском почему то получится другим: to authenticate. И отсюда authentication без "фи". Но сказать authentification не будет большой ошибкой, и в словаре это слово есть. Как если бы существовал глагол "to authentify".
Очень просто. В глаголе "authentifier" имеется "fi". Он означает "certifier l'authenticité" (устанавливать подлинность). От того самого слова "authentique" (lat. authenticus, grec authentikos). Такое уж во французском языке словообразование.
Несколько примеров (парами французский/английский варианты):
… и так далее, можно таких примеров найти очень много.
В английском слова образуются немного по другому, поэтому там этих "фи" нет.
Я не лингвист, если что. Специалист объяснил бы лучше. Но мне кажется это вполне логичным. Может быть просто потому что ухо привыкло. Я живу в городе где большинство людей одинаково хорошо говорят на обоих языках.
Вы правы, транскрипция фамилии /soʊl/, однако в русском разделе Википедии эта страница отсутствует. Непонятно что вы имеете в виду.
Вообще, в американском английском иногда вместо "о" произносят "а". Или, например, проглатывают "т". Есть и другие приколы. Фамилия "Путин" произносится как "Пу'н" (там в середине есть некий неописуемый придыхательный звук), а "водка" звучит больше похоже на "вадка". Может быть любители вадки и искаверкали фамилию уважаемого экономиста?
Похоже, что в русском языке окончательно закрепился французский вариант. Так что всё хорошо, в русском полно заимствований из французского.
https://fr.m.wikipedia.org/wiki/Authentification
А может это был немецкий? :)
https://de.wikipedia.org/wiki/Authentifizierung
А вы приезжайте в Канаду, тут за детей наоборот нехило доплачивает правительство, и медицина бесплатная, школы/садики тоже. Я бы в Штаты ни за что не уехал отсюда, хотя приглашают каждый день.
Сортировка по суррогатному ключу это какой-то очень специфический случай. По крайней мере в моей практике за два десятилетия это встречалось буквально пару раз.
Чаще всего юзеры имеют возможность выбирать поля для (мульти-)сортировки и налагать сколько угодно фильтров. Так что да, придётся таки сканировать всё и потом возвращать кусочек.
Добавьте тег "MySQL", пожалуйста. Все СУБД устроены по своему, и поэтому полезный совет для одной из них чаще всего окажется вредным для другой.
Подтверждаю, тоже имел подобный опыт и не раз.
На самом деле я сморозил глупость. В селектах построчно счётчик так просто не наматывается. Всё немного сложнее, он наматывается внутри хранимых процедур.
Так что теперь точно придётся написать статью с примерами и переводом комментов в коде, чтоб загладить вину :-)
Кстати, Кирилл, можете добавить в вашу статью ещё один способ накрутки счётчика транзакций, о котором мало кто из разработчиков знает.
В PL/pgSQL обработка исключений реализуется при помощи SAVEPOINT. Если в хранимой процедуре/функции имеется блок "EXCEPTION", то при каждом выполнении этого кода будет создаваться SAVEPOINT, и соответственно, будет увеличиваться счётчик транзакций. Если такая функция применяется к возвращаемым строкам запроса, то это может приводить к аварийной остановке кластера, я читал про такие кейсы.
Об этом не сказано в документации, но есть подробный комментарий в исходном коде.
Отсюда вытекает рекомендация. Не используйте обработчики исключений внутри функций, которые вы собираетесь применять к строкам, возвращаемых запросами. Этот механизм предназначен для процедур, реализующих бизнес логику на стороне СУБД,
А, ну точно! Похоже, человек вообще не в теме computer science.
@Терапевт, вы погуглите "сортировку кучей", хоть на той же Википедии. Чтоб в другой раз не опозориться в приличном обществе :)
Кто, что? Куча.
Кем, чем? Кучей.
Кто, что? Куч.
Кем, чем? Кучем.
Разве не так?
Небольшой лайф хак.
Если вы очкарик, как и я, то просто закажите очки на пол-диоптрии послабее. Я так и сделал. Картинка просто отличная, супер сглаженные шрифты, даже на ЭЛТ мониторах. Я не шучу :)
Lombok это препроцессор аннотаций, который, будучи в classpath, автоматически распознается и используется Java компилятором (javac). Ничего в рантайм при этом не привносится. Погуглите интерфейс "javax.annotation.processing.Processor"
Lombok это моя любовь, но даже с его волшебными аннотациями мне хочется большего. Потому я создаю свои аннотации, использую AOP, автоконфигурации и прочую черную магию. Я хочу дакларативного программирования. Очень сложный ядровой код, который спрятан внутри библиотек и инфраструктурных хранимых процедур БД, который правят синьёры-помидоры, и очень простой бизнес код, который с лёгкостью правят новички, следуя простым правилам. Желающие разобраться как всё работает тоже со временем становятся синьёрами.
Вы, конечно же, правы. Я и не спорю с вами, на самом деле. Мне всего лишь не понравились категоричные заявления в стиле Чеховского соседа "этого не может быть, потому что этого не может быть никогда", и я решил высказать альтернативную точку зрения, хотя я знал заранее что в меня полетят помидоры. Мне просто было интересно побеседовать на эту тему.
Я знаю современные официальные рекоменадции, и всю аргументацию, за ними стоящую, и я регулярно смотрю выступления Juergen Hoeller, слушаю Bootiful Podcast by Josh Long и прочих мейнтейнеров этого замечательного фреймворка. Но всё же предпочитаю работать так, как я описал, и этот подход полностью поддерживается и оправдывает себя с годами. И тот же Джош Лонг в своих видео не парится и делает ровно то же самое. На все ваши аргументы я могу привести контраргументы и наоборот.
Мне, кажется, особо нечего добавить к тому, что я написал вам и другим участникам дискусии. Спасибо разработчикам Spring и экосистемы вокруг него за то, что мы, такие разные, можем использовать разные подходы. И спасибо вам за интересную беседу :-)
И ниже я также привёл примеры невозможных внедрений зависимости через конструктор: @PersistenceContext и self-injection.
Вы не поняли, я как раз хочу видеть эти аннотации. Они подчёркивают что это не просто какие-то приватные поля, а именно внешние зависимости, жизненный цикл которых контролируется контейнером. Я открываю код сразу вижу что и как.
Lombok я тоже использую повсеместно, уже много лет, всё что в нем есть.
Для обычных классов (не бинов) я использую конструкторы. Для инфраструктурных бинов, которые создаются автоконгурациями Spring Boot я тоже делаю конструктор. Это совсем другое дело. Таких бинов мало и они очень сложные.
Но для всего остального, обычных сервисных классов, реализующих бизнес логику, я принципиально использую аннотации на приватных полях для наглядности.
Вас не беспокоит что у вас нет конструктора для JpaRepository? Ну вот точно также мне пофигу и на конструкторы для прочих "рядовых" бинов. Мне так нравится, и не вызывает никаких неудобств.