что случилось 1 января 1970 года
Что случилось 1 января 1970 года
Вы наверняка обращали внимание на автоматическую установку даты 1 января 1970 года. Происходит это, если вытащить аккумуляторную батарею или же долго держать iPhone в выключенном состоянии. Именно с этой даты у всех айфонов начинается отсчет времени.
Читаем статью, если вы тоже уже горите любопытством, что же это означает.
Компьютерам нужно знать сколько время.
Для этого было придумано так называемое UNIX-время. Разработчиками стали инженеры исследовательского центра Bell Labs.
UNIX-время определяется количеством прошедших секунд начиная с полуночи 1 января 1970 года. Такой способ удобен при хранении и сравнении дат с точностью до секунд.
Стоит отметить, что 1 января 1970 года это не день рождения Unix. Еще в 1960-ых годах были первые версии операционной системы. Деннис Ритчи один из инженеров-разработчиков говорит, что дата была запрограммирована в систему когда-то в начале 70-х только потому, что это было удобно сделать.
9 сентября 2001 году был юбилей для операционной системы UNIX. 40-я секунда 46-й минуты во втором часу была миллиардной.
Конечно, относительно мало людей думают о времени в 32-битных целых числах. Человеческий разум жаждет круглых чисел, и один миллиард, пожалуй, самый округлый: десять аккуратных цифр, девять из них круглые, как пончик.
1 января 1970 года и iPhone: что это за баг?
В феврале 2016 года появилась очень интересная информация, касаемо операционной системы iOS. Сообщается, что пользователи известнейшего форума Reddit смогли обнаружить критическую уязвимость в операционной системе. Суть в следующем: при переводе даты на 1 января 1970 года и перезагрузке iPhone или iPad превращается в кирпич.
Как обычно, многие пользователи восприняли этот баг как шутку, тем более, что на многих ресурсах о нем рассказывали именно в шутливой форме. Каково же было удивление владельцев устройств, когда последние действительно становились кирпичами!
Процесс таков: нужно было зайти в «Настройки» — «Основные» – «Дата», перевести тумблер «Автоматически» в положение «Выключено» и выставить дату 1 января 1970 года, а время — 1:00 AM или 13:00. После процедуры устройство нужно было обязательно перезагрузить.
После перезагрузки пользователь видел вот что — яблоко на экране, причем постоянно:
В чем причина такого бага? Приводятся следующие версии:
Ошибка была актуальна для iPhone и iPad, построенных на базе процессоров A7, A8, A8X, A9, A9X.
Что касается решения вопроса, то оно, до выхода исправления от Apple, выглядело таким образом:
В iOS 9.3 beta 4 разработчики исправили баг, в результате чего устройство не должно окирпичиваться, если вы введете дату 1 января 1970 года. Но мы ничего гарантировать не можем, так что не рекомендуем выставлять указанную дату. Мало ли что.
Друзья! Если наш сайт помог вам или просто понравился, вы можете помочь нам развиваться и двигаться дальше. Для этого можно:
Apple решение проблемы 01.01.1970
Итак, думаю многие слышали про полное зависание устройств apple при выставлении даты 01.01.1970. Я не исключение и угораздило меня поставить её. Результат ожидаемый iPad Air превратился в высокотехнологичную лопату. Некоторые предлагали разбирать устройство и вытаскивать аккумулятор, некоторые прредлагали подождать, пока пройдёт несколько часов, но я решил проблему другим способом. Пришёл к нму совершенно случайно и не гарантирую, что он будет работать у вас
Вот пошаговая инструкция:
1. Когда устройство зависает на стартовом экране с яблочком нужно просто ждать. Устройство пытается загрузится. И оно загружается. У меня первый раз загрузилось за полчаса. При этом всё дико лагало и при попытке включить настройки устройство вырубилось.
2. Нужно повторять первый шаг пока устройство не загрузится до юзабельного состояния. У меня это произошло на 4 раз. При этом когда устройство загрузится лучше ничего не делать и подождать минут 10. Заметил, что чем больше времени проходит, тем стабильнее он работает. Но процессор при этом очень сильно греется.
3. Когда устройство будет работать оно все равно будет подвисать и лагать. Поэтому нужно быть аккуратным. Я открывал разные приложения. Сначала они вылетали. Потом постепенно начинали работать: часы, телеграм. В итоге настройки открывались, но не отображался текст и приложение вылетало.
4. Спустя попыток 50 все таки открылись настройки и я поставил автоматическое определение часового пояса. Устройство сразу стало работать нормально.
Не знаю чем это объяснить. Может процессор разогревается и начинает работать на полную мощность, вытягивая систему, которая перегружена сбоем из-за даты.
С айпэдом все в порядке, пишу с него. Есть фотографии, где айпэд в окирпиченном состоянии с заветной датой. Выложу, когда будет нормальный интернет. Ну и напоследок, не делайте всё, что пишут в интернете. Надеюсь кому-то поможет, удачи!
Когда то все боялись проблемы 2000, предрекали крах компьютеров, а теперь появилась проблема 1970
На кабель и к тунцу с интернетом!
ПРОВЕРИЛ!! Лечится сбросом батареи! 100%
значит что было.. поставил дату перезапустился. циклический ребут с ромашкой и периодически синим экраном.. греется жестко.. в общем высадил аккум в 0.. разобрал сдернул клемму аккума собрал профит.
Я вот сижу и не понимаю. Объясните, пожалуйста
Если ты знаешь, что стоит поменять дату и устройство умрет (или почти умрет)
Зачем это делать.
(У самого яблоко, но подобным мазохизмом не страдаю)
самое нормальное решение от эпл багов, тупо не покупать эпол
Вот 2 фотки на том этапе, когда он начал работать, но жутко зависал. На первом фото уже удалось вывернуть яркость, на втором ещё не удалось.
Это проклятие Джобса.
Моя маленькая война с Apple
Здравствуйте, появилось желание написать о моём опыте взаимодействия с сервисной службой Apple.
Версия для ЛЛ в конце
Свой планшет iPad pro 12.9 третьего поколения я купил три года назад. Занимаюсь репетиторством, и этот планшет заметно повысил качество моей работы. Три года он служил мне верой и правдой, пока в один ужасный момент он отказался заряжаться.
На тот момент я подумал, что это не лучшее решение в моей жизни. Потратил сутки на прохождение неофициальных сервисных центров. Все они утверждали, что полетел чип быстрой зарядки. Заменить можно, но результат не 100%, и может треснуть экран, а это ещё + 30.000 рублей к ремонту. Взвесив все за и против, отправился в путешествие в сервисный центр Apple.
Глава 5 Разочарование
Ура! Ура! У меня новый планшет! Быстро восстановив учётку, я вернувшись в строй, чувствовал себя на коне. Но конь оказался хромой кобылой, и меньше чем через месяц он сломался. Перестал заряжаться.
Глава 6 Любопытство
Глава 7 Возвращение
Помня, что новый планшет у меня на гарантии, пулей отправился в мой любимый официальный сервисный центр Apple. Там приняли устройство(предварительно проверив, что и от официального шнура он не заряжается) и отправили в Москву. Я засёк две недели.
Вчера мне позвонили и сообщили об отказе в гарантийной замене, так как устройство (по их словам) ремонтировалось на стороне. Чего я явно не делал. Какой адекватный (и неадекватный) человек понесёт гарантийную технику на платный ремонт серым компаниям? На все мои доводы мне дали телефон группы технической поддержки Apple. 8(800)555-67-34.
Сегодня я позвонил по этому телефону. Мне сообщили, что отказ действительно есть, но они не могут раскрывать его детали. Решение принимает какой-то супер секретный супер главный сервисный центр, с которым нет ни физической ни духовной связи. Предложили оставить заявку в сервисный центр, чтобы они попытались призвать дух супер главного и супер секретного сервисного центра.
Пользовался планшетом 3 года. Он сломался. Сделал платную замену. Замена сломалась через месяц. Теперь не хотят делать замену по гарантии. Говорят, планшет был ремонтирован вне сервисного центра Apple. Что является неправдой.
P.S. Кроме тебя, таинственный человек, забраковавший мою заявку.
Apple представила эко-версию iPhone 13, распространяемую без упаковки
Компания Apple объявила о революции в сфере эко-трендов – сегодня была представлена специальная версия смартфона iPhone 13 Biѳ, которая распространяется без заводской упаковки, аксессуаров и инструкций.
Слоганом презентации стала фраза Biѳ Matters. В компании объяснили, что руководство и сотрудники Apple ежедневно и ежесекундно думают о будущем планеты и считают этот вопрос одним из главных вызовов для человечества. Именно поэтому было решено взять курс на отказ от вредных для экологии компонентов – первым из них стала упаковка.
“Свыше 25% упаковок для iPhone выбрасывают в первый же день использования, подобная участь со временем постигает и остальные. Гармоничность и ответственность сообщества Apple продиктовала новый тренд поступать осознанно. Наш долг, как человечества – отказаться от всего, что вредит планете. И сегодня мы объявляем о новой революции – революции, которая открывает путь к спасению Земли. Путь в лучшее будущее. Путь к перевороту в мышлении”, – объявили в пресс-релизе.
Корпорация также отметила, что из-за отсутствия упаковки на iPhone 13 Biѳ может образовываться “естественный транспортировочный рисунок”, придающий каждому аппарату уникальность и подчёркивающий приверженность его владельца “зелёным” трендам.
Ковид теперь как Айфон
Такого больше ни у кого нет
Закон о праве на ремонт может привести к переосмыслению понятия «собственность»
Издание MarketWatch поговорила с экспертами по поводу будущих сложностей исполнения положений закона о праве на ремонт, которое продвигает Федеральная торговая комиссия США (FTC) и президент Джо Байден. По мнению специалистов, бытовая электроника становится все сложнее, что затрудняет самостоятельный ремонт, а также создает риски безопасности. Корпорации все чаще прибегают к созданию собственного оборудования вместо аренды и использования техники других компаний, что делает их поставщиками услуг, а не оборудования. Ремонт потребительских устройств в ближайшие годы станет анахронизмом или хобби, если мировая экономика продолжит политику кредитования, а не закупок, полагают в MarketWatch.
Цель закона о праве на ремонт позволяет потребителям восстановить работоспособность своих устройств самостоятельно или обратиться для этого в неофициальные сервисы. Положение позволит покупателям отказаться от обращения для ремонта к компании-производителю или от принудительного приобретения нового устройства.
Поводом для введения закона стали действия компаний, которые отказывались ремонтировать дорогие товары. В частности, фермеры подали в суд на компанию John Deere & Co. за отказ предоставить им доступ к ПО, который необходим для ремонта сельскохозяйственной техники. Однако в недавнем заявлении компания подчеркнула, что поддерживает право на ремонт.
Apple сама определяет, кому она продает запчасти и инструменты для ремонта. Таким образом, необходимые детали поставляются только официальным представителям компании. Apple часто критикуют за высокую цену ремонта, иногда она доходила до стоимости нового устройства. В то же время, ремонтные работы сторонних компаний гораздо дешевле, однако в их распоряжении значительно меньше запчастей. В 2019 году компания выступая перед Конгрессом посетовала на то, что ее затраты на ремонтные работы уже 10 лет превышают доход от него.
О том, что в каждой отрасли есть крупный доминирующий производитель, рассказал глава Ремонтной ассоциации Гей Гордон-Бирн. Возглавляемая им организация появилась в 2013 году после принятия Закона о праве владельцев транспортных средств на ремонт в штате Массачусетс. Положения обновили в 2020 году и добавили в них электронные данные о транспортных средствах.
По словам Гордона-Брина, компаниям ничего не нужно делать для монополизации ремонта поставляемых ими изделий. Они просто ограничивают доступ к деталям и не оставляют выбора потребителю.
Ассоциация TechNet призывает FTC работать с производителями, поскольку только они способны провести корректный, безопасный и надежный ремонт устройств.
Закон о праве на ремонт поставит под угрозу интеллектуальную собственность компаний и приведет к негативным последствиям для потребителей из-за ненадлежаще выполненных работ, уверены в MarketWatch.
Согласно данным Бюро статистики труда США, индекс потребительских цен для всей потребительской корзины вырос на 48 % в период 1998-2015 годов. ИПЦ ПК и периферии за это время упал на 96 %, телевизоров — на 94 %, фото и аудиоаппаратуры — на 60 %, услуги интернет-провайдеров — 24 %. Стоимость спутникового и кабельного телевидения, напротив, подорожала на 80 %. Эти данные позволяют сделать вывод, что физические продукты все больше зависят от подключения к сети.
Директор по исследованиям Forrester Гленн О’Доннелл считает, что исполнение закона о ремонте затрудняется технической сложностью современных устройств. По его мнению, некоторые компоненты даже не стоит пытаться ремонтировать самостоятельно.
FTC единогласно проголосовала за право на ремонт в июне. Регулятор считает необходимым бороться с ограничениями на ремонтные работы сложных устройств. Ранее Байден подписал указ, который направлен на усиление конкуренции и борьбу с большими компаниями.
Youtube-блогер попытался самостоятельно заменить дисплей на iPhone 13 и обнаружил, что это приводит к отключению системы FaceID. Специалисты объясняют, что это произошло из-за рассоединения программных пар серийных номеров, которые Apple наносит при производстве на определенные детали смартфона. Эксперты iFixit оценили самостоятельную ремонтопригодность iPhone 13 на 5 из 10 баллов.
IT-юмор
3.3K поста 45.2K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору
А 19 января 2038 года, все схлопнется обратно.
Коммент про Брудля.txt
Так как питона тогда не было.
так не было же никакого «до большого взрыва»
А вы говорите Аллаха не существует. А что скажете насчет большого взрыва?
В некоторых летоисчислениях это случилось в 1600-ом
Количество постов про Unix time увеличилось вдвое.жпг
Я узрел истину! Сначала было слово.
Так вот кто виновник моих проблем.
До сих пор не могу понять, как наш мир может существовать?
Когда-то времени не было и все процессы происходили одновременно? Я одновременно не был рождён и одновременно уже умер, одновременно мне 20 лет и 50 лет?
Если пространства не было, то я одновременно и в середине Солнца, и в середине своей квартиры? Всё сущее сконцентрировано везде и нигде?
Но тут тоже хз, если Бог захотел создать время, то это тоже процесс, растянутый во времени.
Короче, мой биологический мозг не может воспринять эту концепцию, как ни старайся.
Без константы time не могло быть «до» и «после», Большого Взрыва не могло бы быть без процессов, протекающих во ВРЕМЕНИ
Ответ на пост «Надёжный план»
Была у меня как то знакомая несколько лет назад. Встречалась пару месяцев с моим другом. Красотка та ещё. К тому же веселая и характером выдалась, ну просто огонь девка. Случилось так, что товарищ с ней расстался, а она через некоторое время начала отношения с программистом, победителем школьных математических Олимпиад, худым высоким очкариком, вылитая копия Билла Гейтса. Красавцем он не был, некоторые девушки так вообще могли бы назвать его отвратительным. Пара поженилась, появились дети и через пару лет он разработал какое-то программное обеспечение, а Гугл купил его у него за очень хорошие деньги. Девчонка сорвала Джекпот! И это ещё до наступления времён всеобщего побега в сферу IT.
Когда решил вкатиться в IT сразу после шараги
Вторая без первой не заведётся
Если бы программист создавал Землю
[Не]эффективный алгоритм прохождения лабиринта
Не украл, а вдохновился архитектурой кода
Вот уже на протяжении нескольких лет Тимофей, преподаватель кафедры информатики МФТИ, выкладывает свои лекции по программированию на своём Youtube канале с открытым доступом.
Не заметил подвоха
Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger
Продолжаем серию материалов про создание системы заметок. В этой части мы спроектируем и разработаем RESTful API Service на Go cо Swagger и авторизацией. Будет много кода, ещё больше рефакторинга и даже немного интеграционных тестов.
В первой части мы спроектировали систему и посмотрели, какие сервисы требуются для построения микросервисной архитектуры.
Подробности в видео и текстовой расшифровке под ним.
Начнём с макетов интерфейса. Нам нужно понять, какие ручки будут у нашего API и какой состав данных он должен отдавать. Макеты мы будем делать, чтобы понять, какие сущности, поля и эндпоинты нам нужны. Используем для этого онлайн-сервис NinjaMock. Он подходит, если макет надо сделать быстро и без лишних действий.
Страницу регистрации сделаем простую, с четырьмя полями: Name, Email, Password и Repeat Password. Лейблы делать не будем, обойдемся плейсходерами. Авторизацию сделаем по юзернейму и паролю.
После входа в приложение пользователь увидит список заметок, который будет выглядеть примерно так:
Интерфейс, который будет у нашего веб-приложения:
— Слева — список категорий любой вложенности.
— Справа — список заметок в виде карточек, который делится на два списка: прикреплённые и обычные карточки.
— Каждая карточка состоит из заголовка, который урезается, если он очень длинный.
— Справа указано, сколько секунд/минут/часов/дней назад была создана заметка.
— Тело заголовка — отрендеренный Markdown.
— Панель инструментов. Через неё можно изменить цвет, прикрепить или удалить заметку.
Тут важно отметить, что файлы заметки мы не отображаем и не будем запрашивать у API для списка заметок.
Полная карточка открывается по клику на заметку. Тут можно сразу отобразить полностью длинный заголовок. Высота заметки зависит от количества текста. Для файлов появляется отдельная секция. Мы их будем получать отдельным асинхронным запросом, который не помешает пользователю редактировать заметку. Файлы можно скачать по ссылке, также есть отдельная кнопка на добавление файлов.
Так будет выглядеть открытая заметка
В ходе прототипирования стало понятно, что в первой части мы забыли добавить еще один микросервис — TagsService. Он будет управлять тегами.
Для страниц авторизации и регистрации нам нужны эндпоинты аутентификации и регистрации соответственно. В качестве аутентификации и сессий пользователя мы будем использовать JWT. Что это такое и как работает, разберём чуть позднее. Пока просто запомните эти 3 буквы.
Для страницы списка заметок нам нужны эндпоинты /api/categories для получения древовидного списка категорий и /api/notes?category_id=? для получения списка заметок текущей категории. Перемещаясь по другим категориям, мы будем отдельно запрашивать заметки для выбранной категории, а на фронтенде сделаем кэш на клиенте. В ходе работы с заметками нам нужно уметь создавать новую категорию. Это будет метод POST на URL /api/categories. Также мы будем создавать новый тег при помощи метода POST на URL /api/tags.
Чтобы обновить заметку, используем метод PATCH на URL /api/notes/:uuid с измененными полями. Делаем PATCH, а не PUT, потому что PUT требует отправки всех полей сущности по спецификации HTTP, а PATCH как раз нужен для частичного обновления. Для отображения заметки нам ещё нужен эндпоинт /api/notes/:uuid/files с методами POST и GET. Также нам нужно скачивать файл, поэтому сделаем метод GET на URL /api/files/:uuid.
Структура репозитория системы
Ещё немного общей информации. Структура репозитория всей системы будет выглядеть следующим образом:
В директории app будет исходный код сервиса (если он будет). На уровне с app будут другие директории других продуктов, которые используются с этим сервисом, например, MongoDB или ELK. Продукты, которые будут использоваться на уровне всей системы, например, Consul, будут в отдельных директориях на уровне с сервисами.
Писать будем на Go
— Идём на официальный сайт.
— Копируем ссылку до архива, скачиваем, проверяем хеш-сумму.
— Распаковываем и добавляем в переменную PATH путь до бинарников Go
— Пишем небольшой тест проверки работоспособности, собираем бинарник и запускаем.
Установка завершена, всё работает
Теперь создаём проект. Структура стандартная:
— cmd — точка входа в приложение,
— internal — внутренняя бизнес-логика приложения,
— pkg — для кода, который можно переиспользовать из проекта в проект.
Я очень люблю логировать ход работы приложения, поэтому перенесу свою обёртку над логером logrus из другого проекта. Основная функция здесь Init, которая создает логер, папку logs и в ней файл all.log со всеми логами. Кроме файла логи будут выводиться в STDOUT. Также в пакете реализована поддержка логирования в разные файлы с разным уровнем логирования, но в текущем проекте мы это использовать не будем.
APIService будет работать на сокете. Создаём роутер, затем файл с сокетом и начинаем его слушать. Также мы хотим перехватывать от системы сигналы завершения работы. Например, если кто-то пошлёт приложению сигнал SIGHUP, приложение должно корректно завершиться, закрыв все текущие соединения и сессии. Хотел перехватывать все сигналы, но линтер предупреждает, что os.Kill и SIGSTOP перехватить не получится, поэтому их удаляем из этого списка.
Теперь давайте добавим сразу стандартный handler для метрик. Я его копирую в директорию pkg, далее добавляю в роутер. Все последующие роутеры будем добавлять так же.
Далее создаём точку входа в приложение. В директории cmd создаём директорию main, а в ней — файл app.go. В нём мы создаём функцию main, в которой инициализируем и создаём логер. Роутер создаём через ключевое слово defer, чтобы метод Init у роутера вызвался только тогда, когда завершится функция main. Таким образом можно выполнять очистку ресурсов, закрытие контекстов и отложенный запуск методов. Запускаем, проверяем логи и сокет, всё работает.
Но для разработки нам нужно запускать приложение на порту, а не на сокете. Поэтому давайте добавим запуск приложения на порту в наш роутер. Определять, как запускать приложение, мы будем с помощью конфига.
Создадим для приложения контекст. Сделаем его синглтоном при помощи механизма sync.Once. Пока что в нём будет только конфиг. Контекст в виде синглтона создаю исключительно в учебных целях, впоследствии он будет выпилен. В большинстве случаев синглтоны — необходимое зло, в нашем проекте они не нужны. Далее создаём конфиг. Это будет YAML-файл, который мы будем парсить в структуру.
В роутере мы вытаскиваем из контекста конфиг и на основании listen.type либо создаем сокет, либо вешаем приложение на порт. Код graceful shutdown выделяем в отдельный пакет и передаём на вход список сигналов и список интерфейсов io.Close, которые надо закрывать. Запускаем приложение и проверяем наш эндпоинт heartbeat. Всё работает. Давайте и конфиг сделаем синглтоном через механизм sync.Once, чтобы потом безболезненно удалить контекст, который создавался в учебных целях.
Теперь переходим к API. Создаём эндпоинты, полученные при анализе прототипов интерфейса. Тут важно отметить, что у нас все данные привязаны к пользователю. На первый взгляд, все ручки должны начинаться с пользователя и его идентификатора /api/users/:uuid. Но у нас будет авторизация, иначе любой пользователь сможет программно запросить заметки любого другого пользователя. Авторизацию можно сделать следующим образом: Basic Auth, Digest Auth, JSON Web Token, сессии и OAuth2. У всех способов есть свои плюсы и минусы. Для этого проекта мы возьмём JSON Web Token.
Работа с JSON Web Token
JSON Web Token (JWT) — это JSON-объект, который определён в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д., а также подписи (signature).
JWT использует преимущества подхода цифровой подписи JWS (Signature) и кодирования JWE (Encrypting). Подпись не даёт кому-то подделать токен без информации о секретном ключе, а кодирование защищает от прочтения данных третьими лицами. Давайте разберёмся, как они могут нам помочь для аутентификации и авторизации пользователя.
Аутентификация — процедура проверки подлинности. Мы проверяем, есть ли пользователь с полученной связкой логин-пароль в нашей системе.
Авторизация — предоставление пользователю прав на выполнение определённых действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
Другими словами, аутентификация проверяет легальность пользователя. Пользователь становится авторизированным, если может выполнять разрешённые действия.
Важно понимать, что использование JWT не скрывает и не маскирует данные автоматически. Причина использования JWT — проверка, что отправленные данные были действительно отправлены авторизованным источником. Данные внутри JWT закодированы и подписаны, но не зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных.
Реализация JWT в нашем APIService:
— Создаём директории middleware и jwt, а также файл jwt.go.
— Описываем кастомные UserClaims и сам middlware.
— Получаем заголовок Authorization, оттуда берём токен.
— Берём секрет из конфига.
— Создаём верификатор HMAC.
— Парсим и проверяем токен.
— Анмаршалим полученные данные в модель UserClaims.
— Проверяем, что токен валидный на текущий момент.
При любой ошибке отдаём ответ с кодом 401 Unauthorized. Если ошибок не было, в контекст сохраняем ID пользователя в параметр user_id, чтобы во всех хендлерах его можно было получить. Теперь надо этот токен сгенерировать. Это будет делать хендлер авторизации с методом POST и эндпоинтом /api/auth. Он получает входные данные в виде полей username и password, которые мы описываем отдельной структурой user. Здесь также будет взаимодействие с UserService, нам надо там искать пользователя по полученным данным. Если такой пользователь есть, то создаём для него UserClaims, в которых указываем все нужные для нас данные. Определяем время жизни токена при помощи переменной ExpiresAt — берём текущее время и добавляем 15 секунд. Билдим токен и отдаём в виде JSON в параметре token. Клиента к UserService у нас пока нет, поэтому делаем заглушку.
Добавим в хендлер с heartbeat еще один тестовый хендлер, чтобы проверить работу аутентификации. Пишем небольшой тест. Для этого используем инструмент sketch, встроенный в IDE. Делаем POST-запрос на /api/auth, получаем токен и подставляем его в следующий запрос. Получаем ответ от эндпоинта /api/heartbeat, по истечении 5 секунд мы начнём получать ошибку с кодом 401 Unauthorized.
Наш токен действителен очень ограниченное время. Сейчас это 15 секунд, а будет минут 30. Но этого всё равно мало. Когда токен протухнет, пользователю необходимо будет заново авторизовываться в системе. Это сделано для того, чтобы защитить пользовательские данные. Если злоумышленник украдет токен авторизации, который будет действовать очень большой промежуток времени или вообще бессрочно, то это будет провал.
Чтобы этого избежать, прикрутим refresh-токен. Он позволит пересоздать основной токен доступа без запроса данных авторизации пользователя. Такие токены живут очень долго или вообще бессрочно. После того как только старый JWT истекает мы больше не можем обратиться к API. Тогда отправляем refresh-токен. Нам приходит новая пара токена доступа и refresh-токена.
Хранить refresh-токены на сервере мы будем в кэше. В качестве реализации возьмём FreeCache. Я использую свою обёртку над кэшем из другого проекта, которая позволяет заменить реализацию FreeCache на любую другую, так как отдает интерфейс Repository с методами, которые никак не связаны с библиотекой.
Пока рассуждал про кэш, решил зарефакторить существующий код, чтобы было удобней прокидывать объекты без dependency injection и синглтонов. Обернул хендлеры и роутер в структуры. В хендлерах сделал интерфейс с методом Register, которые регистрируют его в роутере. Все объекты теперь инициализируются в main, весь роутер переехал в мейн. Старт приложения выделили в отдельную функцию также в main-файле. Теперь, если хендлеру нужен какой-то объект, я его просто буду добавлять в конструктор структуры хендлера, а инициализировать в main. Плюс появилась возможность прокидывать всем хендлерам свой логер. Это будет удобно когда надо будет добавлять поле trace_id от Zipkin в строчку лога.
Вернемся к refresh_token. Теперь при создании токена доступа создадим refresh_token и отдадим его вместе с основным. Сделаем обработку метода PUT для эндпоинта /api/auth, а в теле запроса будем ожидать параметр refresh_token, чтобы сгенерировать новую пару токена доступа и refresh-токена. Refresh-токен мы кладём в кэш в качестве ключа. Значением будет user_id, чтобы по нему можно было запросить данные пользователя у UserService и сгенерировать новый токен доступа. Refresh-токен одноразовый, поэтому сразу после получения токена из кэша удаляем его.
Для описания нашего API будем использовать спецификацию OpenAPI 3.0 и Swagger — YAML-файл, который описывает все схемы данных и все эндпоинты. По нему очень легко ориентироваться, у него приятный интерфейс. Но описывать вручную всё очень муторно, поэтому лучше генерировать его кодом.
— Создаём эндпоинты /api/auth с методами POST и PUT для получения токена по юзернейму и паролю и по Refresh-токену соответственно.
— Добавляем схемы объектов Token и User.
— Создаём эндпоинты /api/users с методом POST для регистрации нового пользователя. Для него создаём схему CreateUser.
Понимаем, что забыли сделать хендлер для регистрации пользователя. Создаём метод Signup у хенлера Auth и структуру newUser со всеми полями для регистрации. Генерацию JWT выделяем в отдельный метод, чтобы можно было его вызывать как в Auth, так и в Signup-хендлерах. У нас всё еще нет UserService, поэтому проставляем TODO. Нам надо будет провалидировать полученные данные от пользователя и потом отправить их в UserService, чтобы он уже создал пользователя и ответил нам об успехе. Далее вызываем функцию создания пары токена доступа и refresh-токена и отдаём с кодом 201.
У нас есть подсказка в виде Swagger-файла. На его основе создаём все нужные хендлеры. Там, где вызов микросервисов, будем проставлять комментарий с TODO.
Создаём хендлер для категорий, определяем URL в константах. Далее создаём структуры. Опираемся на Swagger-файл, который создали ранее. Далее создаём сам хендлер и реализуем метод Register, который регистрирует его в роутере. Затем создаём методы с логикой работы и сразу пишем тест API на этот метод. Проверяем, находим ошибки в сваггере. Таким образом мы создаём все методы по работе с категориями: получение и создание.
Далее создаём таким же образом хендлер для заметок. Понимаем, что забыли методы частичного обновления и удаления как для заметок, так и для категорий. Дописываем их в Swagger и реализуем методы в коде. Также обязательно тестируем Swagger в онлайн-редакторе.
Здесь надо обратить внимание на то, что методы создания сущности возвращают код ответа 201 и заголовок Location, в котором находится URL для получения сущности. Оттуда можно вытащить идентификатор созданной сущности.
В третьей части мы познакомимся с графовой базой данных Neo4j, а также будем работать над микросервисами CategoryService и APIService.