bauhaus

2022-04-27 21:13:55 Закрыл крышку мака, открыл, увидел это.

Подозреваю что это из-за NGINX, хотя фиг знает, может и докер положил мой мак. Открыть/Комментировать

2022-04-27 21:05:52 Сделал чтобы мой мак мог работать как сервер.

Арендовал выделеный IP адрес, поставил NGINX на мак, настроил, привязал в настройках роутера IP и порты мака на внешний IP.

Даже SSL (https) настроил.

Было, на самом деле очень сложно, но меня всегда интересовало как из своего компьютера можно сделать сервер, поэтому очень сложно, но очень интересно.

Теперь по stage.idied.org и api.stage.idied.org я могу получить доступ в приложение. И самое кайфовое – любое изменение на маке в файлах кода (как фронтенда так и бекенда) сразу отражается на сайте, который доступен всем.

Кайф. Открыть/Комментировать

2022-04-27 00:10:18 Сделал такую анимацию на логаут :)

Правда по факту её не будет видно почти всегда, так как сервер быстро отвечает. Открыть/Комментировать

2022-04-26 21:31:17 #music

Очень хорошо.

https://open.spotify.com/track/53dJJQek22fYOLD6tZJpfk Открыть/Комментировать

2022-04-26 15:42:18 Увидел баг.

Решил записать его на видео. Включил запись экрана, начал повторять, а бага нет. Открыть/Комментировать

2022-04-26 08:47:08 Заметил только на скриншоте что забыл выровнять иконку в кнопке. Открыть/Комментировать

2022-04-26 08:44:09 Добавил аватарку текущего пользователя на кнопку “Sign out”.

Самому иногда даже для тестирования нужно знать на каком я щас аккаунте. Открыть/Комментировать

2022-04-26 06:46:18 Максимально одобряю твою идею с авторизацией по куке. Теперь я просто в браузере могу увидеть сходить по API-шной урле и увидеть данные, если нужно что-то быстро проверить Открыть/Комментировать

2022-04-26 05:56:53 Апдейт по idied.org:

1. Сделал отдельный под-домен для API – api.idied.org

2. Позволил бекенду читать кукисы, если запрос был сделан с idied.org на api.idied.org или с localhost на localhost:5001. Там нужно было пропатчить все запросы withCredentials-ом.

Это позволило делать cross-site запросы и следовательно не прибегать к передаче headers в запросе на бекенд для получения данных с него.

Вернул флоу (его сломал бекендер, когда улучшал авторизацию) с редким use case, но все равно хотел чисто для себя сделать челендж и реализовать его. Флоу такой:

1. Unauthorized user goes to api.idied.org/payment
2. User is presented with a popup asking to login to pay
3. User logs in
4. User is redirected to /notes
5. User is redirected to payment page (this step was missing)

То есть в последнем шаге терялось первоначальное состояние пользователя, в котором было указано, что после авторизации нужно было перейти на оплату, если пользователь перешёл по ссылке для оплаты, но при этом был не залогинен.

Плюс немного бесполезный функционал был добавлен (скорее даже лишний и может даже опасный):

На локальном окружении при переходе на домашнюю страницу API подтягивался Swagger (информация про ендпоинты бекенда; localhost:5001). Но при переходе на idied.org/api эта страничка оказывалась пустой. Переход на под-домен проблему решил, но вопрос зачем нужно показывать эту страницу на продаешене всем желающим, – остаётся под сомнением. Открыть/Комментировать

2022-04-24 18:51:48 Адекватно изолировал Dev и продакшен окружения разработки.

Для Angular мне помогли environments, а для бека я использовал два разных docker-compose файла (они у меня и так были – один для прода, другой, – локальный, – для разработки), в которых указал разные переменные окружения (не те, которые в Angular, а те, которые можно увидеть на маке, напечатав в консоли `env`).

Столкнулся с проблемой – кукисы могут ставится на http://localhost (ну как минимум мне об этом заявляет Chrome во вкладке Application > Cookies), а вот достать их уже не получается. Можно достать с адреса типа 127.0.0.1 или 192.168.0.101, гугл не позволяет такие адреса в Authorized redirect URIs (а без адреса в Authorized redirect URIs гугл не даст провести Google Login).

Пришлось возвращать хранение и передачу JWT с фронта на бек.

Только что проверил и гугл разрешил мне поставить 127.0.0.1. Я раньше не замечал этого, потому что он походу ругался когда я вводил этот адрес, а видите ли если ввести его полностью, то не ругается, несмотря на его же заявления.

Прикол. Теперь придется опять убирать хранение и передачу JWT с фронта на бек. Но не беда.

Но вот что действительно беда, – так это то, что с телефона посмотреть локальный сервер можно только по IP адресу внутренней сети. Для меня это 192.168.0.101. То есть никакого тебе http://localhost, никакого http://127.0.0.1, только внутренний адрес.
Оно-то понятно, но напомню еще раз – гугл не позволяет указывать у себя адрес внутренней сети в качестве Authorized redirect URIs.

Так что тут только придумывать какие-то костыли (о которых забудешь и которые могут даже и прод сломать при кривых руках) только ради того, чтобы протестировать твой фронтенд на мобильном телефоне. А без тестирования на реальном мобильном устройстве вообще нельзя ни верстку, ни логику выпускать в прод, там всегда обязательно что-то едет, даже то, что нормально отображается нормально в мобильных эмуляторах (даже официальном от Apple в XCode). Открыть/Комментировать