Сообщения

Сообщения за январь, 2022

algos

 public static T[] slice<T>(T[] l, int from, int to) {     T[] r = new T[to - from];     for (int i = from; i < to; i++)     {         r[i-from]=l[i];     }     return r; } src: https://stackoverflow.com/a/32965043/2910338 

access token vs refresh token differences and why refresh token hasn't been exposed to web browser( SPA among them).

in short: refresh token lived in about a year or more. access token should be valid for a short amount of time. when refresh token compromised it means that hacker can get access for a year. description: refresh token accepts by authentication server with user id and user secret code. access token purpose is to get resources from resourceS servers which can have lacks in security. that's why access token short lived. that's why SPA send to the server email and password over https and then api server which is secured properly send to oauth2 authentication server reguest with user id and user secret. then oauth2 auth server response with access token and refresh token. then api server keeps refresh token locally( it means securely) and response to SPA with only short lived access token. then SPA send access token to resources servers.  so I can conclude access tokens is just the way not to store session through cookies in the case of SPA. and I can assume that SPA should track ex

debugging...

Изображение
 

spring transaction annotation quirks

  По умолчанию Spring откатывает транзакции только в случае   непроверяемого  исключения.   Проверяемые   же считаются «восстанавливаемыми» из-за чего Spring вместо   rollback   делает   commit . Поэтому   personRepository.count()   возращает   2 . Самый простой исправить это — заменить  Exception  на непроверяемое исключение. Например,  NullPointerException . Либо можно переопределить атрибут  rollbackFor  у аннотации. Когда какой-нибудь bean указывает транзакционный сервис в качестве DI зависимости, Spring на самом деле внедряет прокси. Параметр  propagation  у  @Transactional  по умолчанию имеет значение  REQUIRED . Это значит, что новая транзакция создается, если она отсутствует. Иначе выполнение продолжается в текущей. Так что в нашем случае весь запрос выполняется в рамках единственной транзакции. Однако здесь есть нюанс. Если  RuntimeException  был выброшен из-за границ  transactional proxy , то Spring отмечает текущую транзакцию как  rollback-only . Здесь у нас именно такой слу

Рекурсивный запрос на postgres

 src: https://devmark.ru/article/postgres-recursive-query ))