Это, видимо какой-то очень узкий случай когда все, что волнует это просто (но быстро) достать свечи за период времени. Тут, конечно можно и файлов нагенирить и доставать их через nginx, если так уж хочется избежать написания своего бекенда. Однако, во всех реальных случаях работы с market data что я видел/участвовал, подобный уровень сервиса очень быстро перестает быть достаточным и любое новое требование плохо укладывается в описанную схему.
Например, может возникнуть желания перегенрации свечек «на лету» по вполне банальным причинам — не отдавать клиентру слишком много данных. Или, например, поддерживать (для отображения не клиенте) несколько типов интервалов. Такие реагргегации, если их ограничить, можно тоже генерить файликами, однако количество этих видов будет нарастать. Ну а в момент, когда понадобится доставать эти свечи каким-то нетривиальным образом для анализа, наример «взять 10 минутный интервал вокруг daily high price для определенного инструмента», или «вернуть свечи за интервал но отфильтровать по определеному минимальниому vwap» такая схема просто не будет работать.
Воможно, все эти дополнительные возможности и не нужны для работы с крипто-биржами и все что надо это быстро отдавать свечки. Для настощих бирж я видел несколько решений где разработчики пытались оптимизировать хранение market data в наборе своих велосипедных файлов, но все эти решения со временем превращались в свой собственный типа-nosql с индексами, кэшами, распределенностью и прочим, а начальное желания «поменьше бэкенда, сделаем просто на коленке» скоро забывалось и порождало трудно-понимаемых самописных монстров.
В vgo наоборот добавили поддержку vendor не смотря на то, что изначально была идея использовать кэш/прокси. По настоятельным и вполне резонным замечаниям общества эту поддержку ввели. Я не видел намеков на то, что это временно и «в будущем разработчики Go хотят уйти от этого».
Я часто оставляю отзывы на местном (американском) амазоне. Некоторые из них и на 1-2 звезды и за все время был один случай, когда не приняли. Но это, похоже было связано не с review, а с чем-то другим, т.к. отказ пришел прямо в момент нажатия кнопки «submnit».
Все мои review никогда не пропадали. После того, как я поставил 1 звезду firetv 4k и описал какой это отстой, из амазона позвонили и пытались выяснить, что не так с моим устройством и как помочь. Предложили вернуть деньги если полный сброс на заводские настройки не поможет, ревью не удалили и не просили поменять оценку.
ничего не понял. кем отправлятся? что именно слушает клиент? что значит назад?
Насколько я себе представляю, этот рефреш токен должен быть у клиента и получит он его в момент login, вместе с access token, где его, теоретически можно украсть, например если есть физический доступ к компьютеру жертвы. Потом он (клиент) его будет время от времени посылать auth серверу для получения нового access token. Я не вижу как в этой схеме помешать злодею который завладел этим refresh token.
> Компрометация refresh tokenа сама по себе еще не обязательно приведет к возможности получения злоумышленником новых токенов
Вот это мне непонятно. Какой механизм может этому помешать? Передача рефреш токена, как бы она не просиходила, будет идти от клиента к серверу auth и в ответ на валидный refresh token auth server радостно создаст новый access token. Кроме условного «усиления refresh token» путем добавления туда чего-то типа source ip и/или агента или еще нечто в таком роде, я не вижу какой тут механизм помешает.
эээ… а это что? «я лишь подчеркнул что это не правильно...», «вы не правильно пишите что application server должен знать секрет ...»
я не спорю, что для определенных случаев ассиметричный ключ будет безопасней, я всего лишь подчеркиваю, что категоричность приведенных выше цитат не соответствует действительности.
> в примере в статье речь о симметричном шифрование и секрет получается один и тот же что на auth сервисе, что на application.
да, именно об этом и идет речь в статье. И это, повторю в 3й раз, вполне правильная трактовка. С точки зрения JWT нет ничего неправильного в использовании симметричного ключа, это один из легальных способов.
Что касается «удобней» — это уже вопрос к вашей системе. Я могу придумать случаи когда использование HMAC будет удобней, но суть не в этом, а в том, что это один из нормальных методов подписи и верификации JWT.
Нет, смысл вовсе не в этом. Строго говоря «application server может читать данные из payload без ключа» — это очень плохая идея. Никакого доверия таким данным нет и их можно использовать только после того, как сделана проверка подписи. Это действительно делает application server и он делает это на каждый запрос в котором JWT представлен.
Какой-то ключ application server должен знать, но это не обязательно должен быть тот же секрет, который использовался при создании токена. А может быть и тот-же, зависит от Signing Method — HMAC (shared key) или RSA/ECDSA (asymmetric).
> В любом случае — это особенность, которая в «плюсы» точно не попадает.
Это особенность докера вообще, который примерно так работет на всех системах. Я не понимаю как и зачем надо несколько виртуальных машин и для какого именно юзкейс это может быть релевантно.
> если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно
Опять непонятно, какую именно проблему предложенное решения адресует. Телепатически могу догадаться, что речь идет о volumes (исходя из разных упоминаний NFS).
> В комплекте идёт прокси — зачем же изобретать свой велосипед,
Если это используется как среда для локальной разработки, то я могу (с трудом, но могу) представить пользу от подобного. Но если это использование для чего-то более близкого к тому, как докер используют в реальной жизни, то решать «проблему» портов вот этим велосипедом на настощем, боевом сервере — это не самая лушая идея. Для этого есть много разного, готового и проверенного в бою, что умеет делать динамическое проксирование нормальным образом.
> «В качестве слоя виртуализации он использует HyperKit. Недостаток — вы можете использовать только одну виртуальную машину.»
Что-то я не понимаю, в чем суть этой «проблемы». Почему это вообще рассматривается как проблема? В реальном, боевом использовании, тоже будет «всего один докер на хосте», зачем такая пляска с бубном нужна на рабочей машине чтоб поднять их несколько?
По поводу «ужасно медленный» — это про что вообще? Про доступ к хостовой FS? Если он «ужасно медленный» то где результаты того, как он станет «прекрасно быстрым», где бенчмарки подтверждающие это?
Проблема нескольких контейнеров на одном порту — это вовсе не проблема докера и решать ее надо на уровне прокси, который часть вашей системы, а не добавлением магической надстройки над docker-machine.
у вас, какая-то очень особая точка зрения не факты. Вы уже 5 раз сказали про «393 доллара ЕЖЕМЕСЯЧНО» но упорно отказываетесь слышать, когда вам говорят что речь идет о «monthly premiums» и, обычно (практически всегда в области IT) 90%, а бывает и 100% платит работодатель.
Что касается «зачем людям нужна государственная страховка Obamacare» — во первых, она не государственная. Во вторых, если вам кажется, что народ стоит в очередь за этой «государственной страховкой», то оно тоже не так.
это мне кажется просто классическим примером пожелания, нарушающего все идеи и все методы/подходы принятия решений об изменениях в этом языке. То, что такое предложения вообще возникло, скорее всего означает нарушение первого пункта («используй язык, набирай опыт»). Я не могу себе представить как кто-то, кто разрабатывает на Go предложит настолько радикально и калечаще поменять нечто, что совершенно не важно для тех, кто этот код на самом деле пишет. И тут подходим к нарушению второго пункта — а какую проблему это должно решить? Проблемы тут нет никакой, но есть «мне так приятней/привычней, и вообще — хочу как в питоне».
Какая-то, на мой взгляд, бесмысленная тема — «Кто первый сделал запускалку для своих продуктов». Сам смысл этих запускалок не особо ясен, ничего не мешает это сделать 33 другими способами, включая средства ОС и разные универсальные ланчеры типа Alfred. А тут это подается как достижение программистской мысли. Я сильно сомневаюсь, что есть живые люди которые выберут одну IDE вместо другой из за того, что там есть Launcher/Toolbox или нет. Этот фактор, лично для меня, не то что не в первой десятке причин для выбора, но даже и не в первой сотне.
назвать это гордо «интрументом» я бы не решиился. Там весь код это 50-60 строк определяющие структуру параметров, заворачивающие «templates» со всем, что человек туда положил в bindata и делающее по всем файлам в нем filepath.Walk с ExecuteTemplate. Могу, конечно, выложить, просто мне казалось это тривиальным.
Я нежно люблю и активно исползьую gitlab и этот релиз мне нравится, однако приоритеты разработчиков иногда вводят в ступор. В 8.14 поломали совместимость со всеми текущими версиями git (точнее это git поломал, но результат от этого не меняется) и месяц было невозможно никому пушить в protected branch. Починка там была почти тривиальная, но по непостижимым для меня причинам она ждала 8.15, хотя просто просилась и кричала войти в скорейший, минорный релиз 8.14.х
То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.
насколько я вижу, у тебя это тоже типа middlware, но с нестандартной сигнатурой func(http.ResponseWriter, *http.Request) (http.ResponseWriter, *http.Request). Если поменять на func(h http.Handler) http.Handler то станет как у всех, и самое главное — ты сможешь использовать все подобные, готовые middlware без всяких модификаций.
Общее замечание: в принципе, идея создания фреймоврка такого рода мнe кажется делом сомнительным. Во первых, есть неплохие и проверенные боем библиотеки, которые это уже делают основнию часть, например chi. Во вторых — идея добавления туда и конфигурации и еще чего мне не кажется полезной. Да, я понимаю, что при создании сервиса хочется упростить начальные телодвижения, однако лично я пошел по другому пути и написал простой кодо-генератор, который делает рабочий скелет приложения с chi, набором middlware для него (у меня в каждом сервисе надо определенный набор, например JWT), логгером, main с флагами и env (github.com/jessevdk/go-flag) перехватчик сигналов и еще по мелочи. Кроме того, оно генерит не только исходный текст, но и все, что надо для сборки и деплоя (Dockerfile, CI yml, ansible yml)
Например, может возникнуть желания перегенрации свечек «на лету» по вполне банальным причинам — не отдавать клиентру слишком много данных. Или, например, поддерживать (для отображения не клиенте) несколько типов интервалов. Такие реагргегации, если их ограничить, можно тоже генерить файликами, однако количество этих видов будет нарастать. Ну а в момент, когда понадобится доставать эти свечи каким-то нетривиальным образом для анализа, наример «взять 10 минутный интервал вокруг daily high price для определенного инструмента», или «вернуть свечи за интервал но отфильтровать по определеному минимальниому vwap» такая схема просто не будет работать.
Воможно, все эти дополнительные возможности и не нужны для работы с крипто-биржами и все что надо это быстро отдавать свечки. Для настощих бирж я видел несколько решений где разработчики пытались оптимизировать хранение market data в наборе своих велосипедных файлов, но все эти решения со временем превращались в свой собственный типа-nosql с индексами, кэшами, распределенностью и прочим, а начальное желания «поменьше бэкенда, сделаем просто на коленке» скоро забывалось и порождало трудно-понимаемых самописных монстров.
В vgo наоборот добавили поддержку vendor не смотря на то, что изначально была идея использовать кэш/прокси. По настоятельным и вполне резонным замечаниям общества эту поддержку ввели. Я не видел намеков на то, что это временно и «в будущем разработчики Go хотят уйти от этого».
Все мои review никогда не пропадали. После того, как я поставил 1 звезду firetv 4k и описал какой это отстой, из амазона позвонили и пытались выяснить, что не так с моим устройством и как помочь. Предложили вернуть деньги если полный сброс на заводские настройки не поможет, ревью не удалили и не просили поменять оценку.
это не так работает, как совершенно справедливо заметил astec. И в этом легко убедится самому, например так play.golang.org/p/OVcx_zDjDx
Насколько я себе представляю, этот рефреш токен должен быть у клиента и получит он его в момент login, вместе с access token, где его, теоретически можно украсть, например если есть физический доступ к компьютеру жертвы. Потом он (клиент) его будет время от времени посылать auth серверу для получения нового access token. Я не вижу как в этой схеме помешать злодею который завладел этим refresh token.
Вот это мне непонятно. Какой механизм может этому помешать? Передача рефреш токена, как бы она не просиходила, будет идти от клиента к серверу auth и в ответ на валидный refresh token auth server радостно создаст новый access token. Кроме условного «усиления refresh token» путем добавления туда чего-то типа source ip и/или агента или еще нечто в таком роде, я не вижу какой тут механизм помешает.
я не спорю, что для определенных случаев ассиметричный ключ будет безопасней, я всего лишь подчеркиваю, что категоричность приведенных выше цитат не соответствует действительности.
да, именно об этом и идет речь в статье. И это, повторю в 3й раз, вполне правильная трактовка. С точки зрения JWT нет ничего неправильного в использовании симметричного ключа, это один из легальных способов.
Что касается «удобней» — это уже вопрос к вашей системе. Я могу придумать случаи когда использование HMAC будет удобней, но суть не в этом, а в том, что это один из нормальных методов подписи и верификации JWT.
Какой-то ключ application server должен знать, но это не обязательно должен быть тот же секрет, который использовался при создании токена. А может быть и тот-же, зависит от Signing Method — HMAC (shared key) или RSA/ECDSA (asymmetric).
Это особенность докера вообще, который примерно так работет на всех системах. Я не понимаю как и зачем надо несколько виртуальных машин и для какого именно юзкейс это может быть релевантно.
> если ждать загрузки страницы на локальной машине приходится по 15 секунд — это ужасно медленно
Опять непонятно, какую именно проблему предложенное решения адресует. Телепатически могу догадаться, что речь идет о volumes (исходя из разных упоминаний NFS).
> В комплекте идёт прокси — зачем же изобретать свой велосипед,
Если это используется как среда для локальной разработки, то я могу (с трудом, но могу) представить пользу от подобного. Но если это использование для чего-то более близкого к тому, как докер используют в реальной жизни, то решать «проблему» портов вот этим велосипедом на настощем, боевом сервере — это не самая лушая идея. Для этого есть много разного, готового и проверенного в бою, что умеет делать динамическое проксирование нормальным образом.
Что-то я не понимаю, в чем суть этой «проблемы». Почему это вообще рассматривается как проблема? В реальном, боевом использовании, тоже будет «всего один докер на хосте», зачем такая пляска с бубном нужна на рабочей машине чтоб поднять их несколько?
По поводу «ужасно медленный» — это про что вообще? Про доступ к хостовой FS? Если он «ужасно медленный» то где результаты того, как он станет «прекрасно быстрым», где бенчмарки подтверждающие это?
Проблема нескольких контейнеров на одном порту — это вовсе не проблема докера и решать ее надо на уровне прокси, который часть вашей системы, а не добавлением магической надстройки над docker-machine.
Что касается «зачем людям нужна государственная страховка Obamacare» — во первых, она не государственная. Во вторых, если вам кажется, что народ стоит в очередь за этой «государственной страховкой», то оно тоже не так.
То, что авторы прокручивают новые свистелки — это конечнно хорошо, но то, что они стремительно теряют интерес к старым — это грустно. Месяца три как ждем элементарной починки для registry чтоб с ним наконец можно было работать, но нет — новые странные штуки появляются, а допилить то, что было выпущено несколько месяцев назад — никак.
Общее замечание: в принципе, идея создания фреймоврка такого рода мнe кажется делом сомнительным. Во первых, есть неплохие и проверенные боем библиотеки, которые это уже делают основнию часть, например chi. Во вторых — идея добавления туда и конфигурации и еще чего мне не кажется полезной. Да, я понимаю, что при создании сервиса хочется упростить начальные телодвижения, однако лично я пошел по другому пути и написал простой кодо-генератор, который делает рабочий скелет приложения с chi, набором middlware для него (у меня в каждом сервисе надо определенный набор, например JWT), логгером, main с флагами и env (github.com/jessevdk/go-flag) перехватчик сигналов и еще по мелочи. Кроме того, оно генерит не только исходный текст, но и все, что надо для сборки и деплоя (Dockerfile, CI yml, ansible yml)