Никакой разницы. В интернете я товар без всяких кассиров заказываю. Кассир скорей всего - это лишь легаси "прибор для работы с наличкой". Вы же человеку в чек не записываете "Услуги кассира - 10 р". Попробуйте записать, вам такой скандал устроят по навязанным платным услугам )
Если рассматривать целевую систему, то ИМХО должно быть некое отдельное приложение (да, конечно всегда все можно совместить в одно при большом желании), которое оперирует файлами и\или блобами (загружает во временное хранилище и отдает ссылку клиенту), а клиент в json-rpc уже передает ссылку на ресурс (или его идентификатор)
В реальном приложении вряд ли удастся забыть про HTTP окончательно: как-то надо управлять кэшированием, принимать и отдавать BLOB'ы и файлы (в параллель с JSON-RPC, видимо)
Если мы говорим про json-rpc приложение, то строго говоря стоит забыть, потому что json-rpc это по определению transport agnostic протокол.
JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over http, or in many various message passing environments
Как только вы завязываетесь в своем протоколе на http, половина того, что напридумана в json-rpc становится совершенно избыточной, а вторая половина - неудобной. Становится гораздо проще взять кастомный json-based протокол и описать его в openapi и реализовывать все стандартными инструментами для чего есть куча готовых библиотек.
От JSON-RPC остались только Request и Response в качестве соглашения о структуре конкретного API, и то, ни "jsonrpc", ни "id" не используются.
Работал в паре компаний где в качестве базового межсервисного протокола (еще задолго до моего прихода) был выбран json-rpc, ни в одной из них правильно его приготовить не смогли, в итоге везде получалось примерно это же самое, на что вы сетуете, оставался некий +- фиксированный конверт и "контракт", который можно было сделать гораздо удобней
Что именно вы продаете зависит от того, что именно вы делаете.
Вы можете продавать прототипы как товар, как указал E_BEREZIN неограниченному кругу лиц (еще кстати вы можете исключительные продавать права, как товар, но это отдельная история)
Вы можете выполнить работу по разработке такового прототипа (например по договору подряда или иному)
А можете оказать заказчику набор возмездных услуг которые помогут ему самостоятельно разработать таковой прототип (например обучить его команду)
Обслуживание клиента на кассе — это ведь всё-таки услуга, а не товар?
Обслуживание на кассе - не услуга, а оформление\соблюдение юридических формальностей\обязательствы. Вы не можете их не выполнить, чтобы осуществить продажу.
ну, это уже руки производителя кривые. тут, мне кажется, не важно, андроид он там ждет для загрузки или свою проприетарную прошивку - через жопу можно сделать все что угодно.
А ещё там вроде пульт блютусный, который не работает, пока андроид не загрузится.
Недавно открыл для себя, что смарт-тв устаревают так же безбожно, как и смартфоны и, казалось бы, купленный всего 6 лет назад смарт-ТВ уже не такой и смарт и на него, например, уже не поставить нативное приложение для jellyfin (поставить можно через режим разработчика, но работать не факт что будет).
В следующий раз когда (если?) я буду смотреть на ТВ, скорей всего буду рассматривать для себя комбинацию какого-нибудь максимально простого (но качественного тв) + приставка, которую можно будет в случае чего просто заменить на более свежую.
+ Кажется приставка с точки зрения проблем описанных в статье более кастомизируема (вплоть до того, чтобы использовать полностью свою малинку в качестве таковой)
Если например на вайлберис/озон, кто-то продаст ворованный или незаконный продукт, его точно так же изымут и оплату покупателю не вернут.
Разница в том, что в случае с ником его изымет у вас сам телеграм. В случае кривого товара на озоне я не вижу сценария, при котором мне не должны вернуть оплату. Если его изъяли до передачи мне - то договор купли продажи не был исполнен и деньги просто обязаны вернуть. Если после, то я вполне уверен, что от органов, которые товар изымут можно получить соответствующий документ, подтверждающий причину изъятия, после чего вернуть деньги в претензионном порядке.
В случае с телеграмом вы в лучшем случае можете написать в спортлото, потому что, как уже отметили выше, Fragment не афиллирует себя с Telegram да и законы, по которым работает сервис не очень понятны
Это приложение не является полноценной ОС Debian - это уровень совместимости, основанный на PRoot, который позволяет запускать приложения Debian, созданные пользователем. Ваш телефон не рутируется во время установки. Запуск Wireshark или Aircrack-ng не удастся, потому что они требуют root. Это не официальный выпуск Debian.org.
По описанию это user-space chroot, так что сомневаюсь что там заведется хотя бы докер
простите, а "Двух-трёх летний флагманский телефон" можно сцепить с usb3 хранилкой для хранения терабайтов порно? а подцепить к гигабитной сети, чтобы просматривать его в 4к с тв? не говоря уж о том, что о настройке rpi написано в каждой подворотне, кажется, уже, а вот инструкций "собириаем home lab на древних мобилах" я чет особо не встречал. Есть нормальные образы OS, которые полноценно поддерживаются, на которые встанет без бубна докер?
понятно что можно найти дешевый телефон. будет ли он полноценной заменой, помимо того, что он быстрей?
больше соглашусь с комментаторами выше, что дешевле взять бу комплектухи десктопной теперь, чем малину, эт печальный, но факт
Ху из райт, соответственно. Потому как уже 3 мнения.
Подпись - это часть токена. Ее не надо расшифровывать. Можно весь токен целиком проверять. Суть та же, только кмк дольше просто. Вероятность совпадения подписей крайне мала. Проверять нужно только в случае если у вас реализован бан-лист. Если бан-листа нет - то можно и не проверять, но в таком случае рекомендовал бы сделать access token максимально коротким (1-2 минуты), чтобы их не надо было бы банить.
От чего это зависит?
От ваших политик безопасности и сценариев поведения. В целом у рефреш токена одна цель - получать новый access token. Сколько он будет жить - зависит от того, как часто идут обращения к защищенному эндпоинту. Очевидно, что если они идут реже, чем время жизни рефреш токена, то вся схема коту под хвост.
Поэтому универсальных цифр никто не даст, выбирайте под свой юзкейс.
А тут получается и расшифровка и доступ к базе. Смысл?
Токен не надо расшифровывать. достаточно проверять, например, что подписи нет в БД.
доступ к базе / редису, то есть проблема скейлинга всё равно присутствует
Принудительный отзыв - операция не очень частая, хранить (см. выше) достаточно хвост и дату истечения (в виде даты истечения записи), поэтому база не оч. большая. у токенов есть время жизни, поэтому база не пухнет бесконечно. Поэтому такую базу достаточно легко реплицировать - проблема скейлинга не такая серьезная, чем если надо реплицировать сессионные данные (которые еще и меняются по ходу дела, а подписи токенов статичны - там нет изменяемых данных). Справятся несколько мемкэшей\редисов\etc
revoke token для запроса нового токена и логаута. Но мы не можем её же использовать, она у нас за бан лист отвечает.
Не очень понял проблему. Принудительный логаут - это по сути тот же принудительный бан токена, только с UX нормальным. Если токен при логауте не банить, то им может воспользоваться кто-нибудь, да.
А как понять, кого в бан лист добавлять? И почему добавлять нужно? Я же не знаю, что его спёрли. Знал бы, не дал бы спереть.
Обычно сервисы это реализуют в виде "смотри, чувак, ты зашел с нового устройства, проверь если это был не ты" и списка сессий где-нибудь в UI, где можно убить все остальные сессии принудительно (в т.ч. рефреш). А вообще утекание рефреш токена равносильно утеканию куки с сессией по масштабам бедствия. Защищаться можно, в целом, теми же способами, например зашивать в токен IP получателя (что немного не крутой UX иногда, но зато чуть надежней)
Никакой разницы. В интернете я товар без всяких кассиров заказываю. Кассир скорей всего - это лишь легаси "прибор для работы с наличкой". Вы же человеку в чек не записываете "Услуги кассира - 10 р". Попробуйте записать, вам такой скандал устроят по навязанным платным услугам )
Если рассматривать целевую систему, то ИМХО должно быть некое отдельное приложение (да, конечно всегда все можно совместить в одно при большом желании), которое оперирует файлами и\или блобами (загружает во временное хранилище и отдает ссылку клиенту), а клиент в json-rpc уже передает ссылку на ресурс (или его идентификатор)
Если мы говорим про json-rpc приложение, то строго говоря стоит забыть, потому что json-rpc это по определению transport agnostic протокол.
https://www.jsonrpc.org/specification#overview
Как только вы завязываетесь в своем протоколе на http, половина того, что напридумана в json-rpc становится совершенно избыточной, а вторая половина - неудобной. Становится гораздо проще взять кастомный json-based протокол и описать его в openapi и реализовывать все стандартными инструментами для чего есть куча готовых библиотек.
Работал в паре компаний где в качестве базового межсервисного протокола (еще задолго до моего прихода) был выбран json-rpc, ни в одной из них правильно его приготовить не смогли, в итоге везде получалось примерно это же самое, на что вы сетуете, оставался некий +- фиксированный конверт и "контракт", который можно было сделать гораздо удобней
А зачем пол-литра? Это же вполне себе юридические термины, которые вполне себе нормально описаны
http://www.consultant.ru/document/cons_doc_LAW_131885/408deb9a985dae8c5008e766865a0b0e4f6e4a0d/
Есть товар, работа и услуга.
Что именно вы продаете зависит от того, что именно вы делаете.
Вы можете продавать прототипы как товар, как указал E_BEREZIN неограниченному кругу лиц (еще кстати вы можете исключительные продавать права, как товар, но это отдельная история)
Вы можете выполнить работу по разработке такового прототипа (например по договору подряда или иному)
А можете оказать заказчику набор возмездных услуг которые помогут ему самостоятельно разработать таковой прототип (например обучить его команду)
Обслуживание на кассе - не услуга, а оформление\соблюдение юридических формальностей\обязательствы. Вы не можете их не выполнить, чтобы осуществить продажу.
ну, это уже руки производителя кривые. тут, мне кажется, не важно, андроид он там ждет для загрузки или свою проприетарную прошивку - через жопу можно сделать все что угодно.
А, простите, как оно включает этот тв?
а какая в этом проблема? каналы еще могу представить (по теме статьи), а по входам чет не идут кейсы в голову
ну или из-за того, что производитель хочет продать новую модель, а не заниматься поддержкой старой
Я не думаю что с производительностью есть какие-то существенные проблемы, но вот с обновлениями...
Недавно открыл для себя, что смарт-тв устаревают так же безбожно, как и смартфоны и, казалось бы, купленный всего 6 лет назад смарт-ТВ уже не такой и смарт и на него, например, уже не поставить нативное приложение для jellyfin (поставить можно через режим разработчика, но работать не факт что будет).
В следующий раз когда (если?) я буду смотреть на ТВ, скорей всего буду рассматривать для себя комбинацию какого-нибудь максимально простого (но качественного тв) + приставка, которую можно будет в случае чего просто заменить на более свежую.
+ Кажется приставка с точки зрения проблем описанных в статье более кастомизируема (вплоть до того, чтобы использовать полностью свою малинку в качестве таковой)
Заголовок: А не запилить ли нам хардварный чат?
Статья: Полностью софтварный чат на MQTT и COM, железки чисто для виду, в качестве wifi модема\mqtt-клиента )
Я удивлен что не 77. Получается не очень выгодно )
Разница в том, что в случае с ником его изымет у вас сам телеграм. В случае кривого товара на озоне я не вижу сценария, при котором мне не должны вернуть оплату. Если его изъяли до передачи мне - то договор купли продажи не был исполнен и деньги просто обязаны вернуть. Если после, то я вполне уверен, что от органов, которые товар изымут можно получить соответствующий документ, подтверждающий причину изъятия, после чего вернуть деньги в претензионном порядке.
В случае с телеграмом вы в лучшем случае можете написать в спортлото, потому что, как уже отметили выше, Fragment не афиллирует себя с Telegram да и законы, по которым работает сервис не очень понятны
А встренная в проц прокатит?
Там прямым текстом написано
По описанию это user-space chroot, так что сомневаюсь что там заведется хотя бы докер
Хм, надо бы попробовать. на рабочем маке сетевуха в моем хабе не заработала без установки дров
более того плекс - это распределенное, а не только на одном тв. можно смотреть везде, где есть приложение (на худой конец - браузер)
простите, а "Двух-трёх летний флагманский телефон" можно сцепить с usb3 хранилкой для хранения терабайтов порно? а подцепить к гигабитной сети, чтобы просматривать его в 4к с тв? не говоря уж о том, что о настройке rpi написано в каждой подворотне, кажется, уже, а вот инструкций "собириаем home lab на древних мобилах" я чет особо не встречал. Есть нормальные образы OS, которые полноценно поддерживаются, на которые встанет без бубна докер?
понятно что можно найти дешевый телефон. будет ли он полноценной заменой, помимо того, что он быстрей?
больше соглашусь с комментаторами выше, что дешевле взять бу комплектухи десктопной теперь, чем малину, эт печальный, но факт
Подпись - это часть токена. Ее не надо расшифровывать. Можно весь токен целиком проверять. Суть та же, только кмк дольше просто. Вероятность совпадения подписей крайне мала. Проверять нужно только в случае если у вас реализован бан-лист. Если бан-листа нет - то можно и не проверять, но в таком случае рекомендовал бы сделать access token максимально коротким (1-2 минуты), чтобы их не надо было бы банить.
От ваших политик безопасности и сценариев поведения. В целом у рефреш токена одна цель - получать новый access token. Сколько он будет жить - зависит от того, как часто идут обращения к защищенному эндпоинту. Очевидно, что если они идут реже, чем время жизни рефреш токена, то вся схема коту под хвост.
Поэтому универсальных цифр никто не даст, выбирайте под свой юзкейс.
Токен не надо расшифровывать. достаточно проверять, например, что подписи нет в БД.
Принудительный отзыв - операция не очень частая, хранить (см. выше) достаточно хвост и дату истечения (в виде даты истечения записи), поэтому база не оч. большая. у токенов есть время жизни, поэтому база не пухнет бесконечно. Поэтому такую базу достаточно легко реплицировать - проблема скейлинга не такая серьезная, чем если надо реплицировать сессионные данные (которые еще и меняются по ходу дела, а подписи токенов статичны - там нет изменяемых данных). Справятся несколько мемкэшей\редисов\etc
Не очень понял проблему. Принудительный логаут - это по сути тот же принудительный бан токена, только с UX нормальным. Если токен при логауте не банить, то им может воспользоваться кто-нибудь, да.
Обычно сервисы это реализуют в виде "смотри, чувак, ты зашел с нового устройства, проверь если это был не ты" и списка сессий где-нибудь в UI, где можно убить все остальные сессии принудительно (в т.ч. рефреш). А вообще утекание рефреш токена равносильно утеканию куки с сессией по масштабам бедствия. Защищаться можно, в целом, теми же способами, например зашивать в токен IP получателя (что немного не крутой UX иногда, но зато чуть надежней)