Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Через device ты все равно открываешь системный браузер, только на другом устройстве.
Ровно один раз.

Здравствуйте, Pauel, Вы писали:

P><CreatorCray on>
P>Я пишу на Фортране, я практик, на моей машине ничего кроме Фортрана нет. Веб — не нужен!!!!!11111111йййййqqqqqкукуку
P><CreatorCray off>

Икемфула пытается прикидываться Артёмкой но у него даже это не получается

Здравствуйте, Pauel, Вы писали:

P>>Могу продолжить: у меня на машине Фортрана нет, но и без него я не пишу для Веба. Значит, Веб не нужен! 11111111
P>Это уже не Cray а kolesiki/baiker
У меня таки фортрана никогда не было, так что даже тут ты мимо
Веб пусть остаётся в браузере. Вебоформоклёпы, воображающие что у них в руках молоток, и потому всё выглядит как гвоздь — не нужны.

Здравствуйте, Pauel, Вы писали:

P>Скайп работает на хрен знает скольки платформах
Телега точно так же работает и функционально на порядок лучше.

P> и приносит деньги
за бесплатные звонки что ли?

Здравствуйте, 4058, Вы писали:

P>>А можно подробнее, как можно заработать на переписывании бесплатного калькулятора?
4>Также, как и на переписывании мессенджера (типа Skype).
4>Захочет M$ распространить его за пределами Windows, возьмёт и перепишет на Electron. Станет прекрасен как Skype, т.е. не будет ощутимо лагать начиная с Core i5 с 8 Гб оперативки.
Slack написан на Electron, а летает. Даже для компаний, в которых в нём терабайты данных.

Так что дело тут не в Electron, а в кривизне рук.

Здравствуйте, Cyberax, Вы писали:

C>Slack написан на Electron, а летает.
Глючит вот только капец. Ну и там тормозить то в общем нечему.

C> Даже для компаний, в которых в нём терабайты данных.
Они ж на серверсайде.

Здравствуйте, CreatorCray, Вы писали:
CC>Я удивлён что ты прогноз погоды туда не притянул.
Да, а ещё — прогноз погоды.

CC>При этом по твоей ссылке совсем не калькулятор
Отчего же? Это как раз штука, которая умножает сумму в дирхемах на их курс. Как по мне — так это аккурат калькулятор.
Если мне нужно посчитать что-то более сложное — ну, например, сравнить, что выгоднее — купить отель в тематическом парке (в стоимость войдут билеты), или обычный отель рядом + билеты отдельно, то я пойду и создам гугл спредшит.
Потому, что
1. Все шаги вычисления наглядно показаны
2. Если я налажал при вводе первого числа в спредшите, то я могу просто пойти и исправить ошибку.
3. Когда мне потребуется аргументировать принятое решение жене, я просто кину ей ссылку на документ.

Здравствуйте, Serginio1, Вы писали:

S>Хотя опять же можно форму запросить и не показывать пользователю, а передать данные из нативной формы. Это просто лень некоторых товарищей

1. UX от ленивых товарищей:

— Нажать кнопку в браузере

2. UX от неленивых

— Ввести логин
— Ввести пароль
— Ввести код 2FA

Идите как вы нафиг неленивые мои.

Здравствуйте, CreatorCray, Вы писали:

P>>Скайп работает на хрен знает скольки платформах
CC>Телега точно так же работает и функционально на порядок лучше.

Что именно там на порядок лучше?

P>> и приносит деньги
CC>за бесплатные звонки что ли?

Похоже, ты снова в теме. В скайпе есть вполне очевидная монетизация. Странно, что такой серьезный знаток не может этого рассмотреть.

Здравствуйте, CreatorCray, Вы писали:

P>>Например, ревью — вместо того, что бы отсылать туда-сюда, документ расшаривается на комменирование, и все видят чужие правки и комментарии.
CC>Для collaboration есть сразу ориентированные на подобную работу сайты, типа того же Atlassian Confluence.

Этого мало. По сравнению с офисом конфлюэнц убог донельзя. Мелкие статейки можно делать, для внутреннего пользования — документация, скажем. Чтото более серьезное — спредшиты, слайды, итд, конфлюенц уже всё.

P>>Онлайн офисы это тоже реалии, только ты ими не пользуешься.
CC>Потому что у меня есть нормально работающий (в отличие от) локальный софт.

Вот-вот.

P>> И калькуляторы в виде веб-приложений, тоже реалии, а ты про них ничего не знал всего неделю назад.
CC>Потому что у меня есть нормальный локальный калькулятор.

Именно, про то и речь — что дальше своего компа носа не высовываешь

P>>В вебе проекты стартуют каждый день. Но ты этого не видишь, потому что зациклен исключительно не себе.
CC>Потому что мне надо решать мои задачи, и я выбираю под них наиболее оптимальное решение.

А разве речь про твои задачи?

Здравствуйте, CreatorCray, Вы писали:

НС>>А если они есть, то это только лишние заморочки.
CC>Как раз наоборот, минимум заморочек.

Дополнительно открывать в браузере ссылку и вводить руками код это минимум заморочек? И хорошо если девайс QR код умеет показывать.

Здравствуйте, Serginio1, Вы писали:

НС>>
S> Ну вот объясни мне зачем для апи браузер?

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

S> Бред!
S> Да сервис конечно сам может такую авторизацию сделать, но почему то не делают!

Все вокруг идиоты потому что, кроме тебя.

Здравствуйте, CreatorCray, Вы писали:

НС>>Только пока refresh token не протух. Он, конечно, обычно месяца три живет и "эксперты по безопасности" про это забывают.
CC>Гуглотокен для девайса живёт с 2014го и всё никак не протухнет.

Ну так тоже можно. Главное чтобы токен не утек.
Но в большинстве случаев либо ты вообще не управляешь временем жизни, и оно в районе 1-3 месяцев, либо все таки есть варианты его указать, но там обычно ограничение на максимальное в районе года.

Здравствуйте, CreatorCray, Вы писали:

НС>>Через device ты все равно открываешь системный браузер, только на другом устройстве.
CC>Ровно один раз.

А это уже неважно. С auth code flow все ровно то же самое — один раз открываешь со скоупом offline_access и, если оно разрешено, получаешь refresh token. Но это все равно надо сделать, без браузера никак.
Без браузера есть ROPC, и ты прекрасно можешь про его безопасность погуглить сам.

Здравствуйте, CreatorCray, Вы писали:

S>>И вдруг мы перепрыгнули с топологии деплоймента к технологии отображения.
CC>Это ты у икемфулы спроси с какого перепугу он начал рассказывать про сайты когда речь шла про аппу на локальной машине.

Потому, что именно сайты вытесняют десктоп. Вот например https://learn.microsoft.com/en-us/microsoft-edge/progressive-web-apps-chromium/ux

Т.е. сайт интегрируется в windows ui. Собтственно, таким образом ты можешь чуть не что угодно заинсталировать.

Электрон нужен только в том случае, если нужны локальные ресурсы.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>
S>> Ну вот объясни мне зачем для апи браузер?

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

S>> Бред!
S>> Да сервис конечно сам может такую авторизацию сделать, но почему то не делают!

НС>Все вокруг идиоты потому что, кроме тебя.
Ну так объясни мне тупому зачем на сервере клиенте апи использовать браузер при протухшем рефреш токене?
Через клиента апи работают сотни клиентов. И вдруг рефрештокен протух.
Нужно искать админа. Отсылать ему сообщения на почту, телефон. Он в это время где то в больнице. И все ждут ну кто же вобьет в браузере логи пароль получит код подтверждения. Наконец получит этот рефрештокен через Cef или Selenium приложение и забросит рефреш токен на клиента апи.

Не ну я конечно тупой! Поэтому наверное и делают непротухаемые рефреш токены!

Здравствуйте, Serginio1, Вы писали:

НС>>Все вокруг идиоты потому что, кроме тебя.
S>Ну так объясни мне тупому зачем на сервере клиенте апи использовать браузер при протухшем рефреш токене?

8.12. Embedded User-Agents

Section 9 of OAuth 2.0 [RFC6749] documents two approaches for native
apps to interact with the authorization endpoint. This best current
practice requires that native apps MUST NOT use embedded user-agents
to perform authorization requests and allows that authorization
endpoints MAY take steps to detect and block authorization requests
in embedded user-agents. The security considerations for these
requirements are detailed herein.

Embedded user-agents are an alternative method for authorizing native
apps. These embedded user-agents are unsafe for use by third parties
to the authorization server by definition, as the app that hosts the
embedded user-agent can access the user's full authentication
credential, not just the OAuth authorization grant that was intended
for the app.

In typical web-view-based implementations of embedded user-agents,
the host application can record every keystroke entered in the login
form to capture usernames and passwords, automatically submit forms
to bypass user consent, and copy session cookies and use them to
perform authenticated actions as the user.

Even when used by trusted apps belonging to the same party as the
authorization server, embedded user-agents violate the principle of
least privilege by having access to more powerful credentials than
they need, potentially increasing the attack surface.

Encouraging users to enter credentials in an embedded user-agent
without the usual address bar and visible certificate validation
features that browsers have makes it impossible for the user to know
if they are signing in to the legitimate site; even when they are, it
trains them that it's OK to enter credentials without validating the
site first.

Aside from the security concerns, embedded user-agents do not share
the authentication state with other apps or the browser, requiring
the user to log in for every authorization request, which is often
considered an inferior user experience.

S>Через клиента апи работают сотни клиентов.

Какие такие сотни клиентов? Мы вроде про десктопный софт говорили.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Через клиента апи работают сотни клиентов.

НС>Какие такие сотни клиентов? Мы вроде про десктопный софт говорили.
Ну начали то про десктоп. А у меня на работе как раз задачка встала. Поэтому есть некий сервис аналог 1С. С ним надо работать через Oath2.
Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
В итоге у них есть свой апи, через который работают через HTML так и апи на мобильных и десктопах.

У них есть методы для обновления рефрештокена с передачей предыдущего, но это надо делать постоянно с некоторой периодичностью.

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

Здравствуйте, Serginio1, Вы писали:

НС>>Какие такие сотни клиентов? Мы вроде про десктопный софт говорили.
S> Ну начали то про десктоп.

А, то есть ты опять сменил тему, да еще забыл об этом остальным сказать.

S>А у меня на работе как раз задачка встала. Поэтому есть некий сервис аналог 1С. С ним надо работать через Oath2.

Не, ты реальнго тугой. Сколько раз в этом топике я написал, что для server 2 server коммуникаций предназначен client credentials? Сколько раз мне еще надо написать, чтобы до тебя наконец это дошло?
Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
Все остальный варианты небезопасны и применять их не следует.

S>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>В итоге у них есть свой апи

У кого у них?

S>Просто задумывали одно, а получилось совсем другое.

Или просто кто то чего то не понимает и несет бред.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Еще раз для особо непробиваемых. Для OAuth2 есть ровно 3 актуальных способа логина:
НС>1) Auth code flow. Открывает системный браузер на том устройстве, где выполняется логин.
НС>2) Devide code flow. То же самое, но браузер можно руками открыть на любом устройстве вводя специальный урл и device код руками или через QR, что позволяет логиниться на устройствах без браузера и даже клавиатуры.
НС>3) Client credentials. Для сценария когда взаимодействуют два сервиса, развернутых в контролируемом с точки зрения безопасности окружении (на своем сервере), браузер не нужен, используется shared secret в виде некоей секретной строки или серта. При этом, разумеется, необходимо безопасное хранение этого секрета, поэтому и не годится для развертывания на клиентских устройствах, а тем более при работе в браузере.
НС>Все остальный варианты небезопасны и применять их не следует.
Вот у них Client credentials. Но нужен рефрештокен. Который достается через cef или selenium приложение.
Который обновляется по старому рефрештокену. После обновления страрый рефрештокен протухает.

S>>Изначально они задумывали только как вэб. Но потом оказалось, что нужно работать через кучу устройств где проще работать через приложения и обмениваться данными с сервисом.
S>>В итоге у них есть свой апи

У сервиса с которым я работаю.

S>>Просто задумывали одно, а получилось совсем другое.

НС>Или просто кто то чего то не понимает и несет бред.
Ну те люди кто с ними контактировали все прекрасно понимают. Не такие тупые как я. Ну я и код вижу, их кстати библиотеки. При авторизации идет передача рефреш токена и получается новый или текущий рефрештокен. Поинтересуюсь конечно еще.
Но ругаются многие клиенты.