Я уважаю ваше желание жить в розовом мире и считать, что у нас что ни компания то обязательно Яндекс. Вот только я видел и работал с проектами не только в больших компаниях, но и с теми что приносят заказчики на фрилансе. И именно поэтому я с такой уверенностью вам говорю, что не все компании это Яндекс и не все делают все идеально. И даже не у всех самые новые технологии используются (но тут вы точно не поверите и скажите что я шучу)
Я действительно не совсем понимаю что вы имеете ввиду под парольной авторизацией (явно не то что я). Авторизация по логину + паролю, действительно почти (именно почти) нигде не используется. О чем в статье также написано. Тем не менее она использовалась раньше и поэтому нужно упомянуть о ней, чтобы было с чем сравнивать.
То что вы при авторизации вводите и логин и пароль это естественно. Здесь вопрос в том какие данные хранить в браузере для последующего взаимодействия. Можно ведь в localstorage сохранить логин и пароль и постоянно их на сервер отправлять. А при авторизации через gmail использется OAuth, который использует токены, а не просто логин и пароль
Слушайте, не спорю что статья не описывает все детали (ровно как и любая статья). Как минимум на практике не встречал статьи, которая отвечала бы на все вопросы.
Второй момент, да мы можем действительно хранить данные о времени жизни ни в самом токене, а в БД, но как вы и сказали это одна из реализаций (более сложная). Статья расчитана на людей, которые эту авторизацию хотят сделать сами у себя. Вот ответьте, если бы у вас были низкие знание о разработке, то какой из видов refresh токена выбрали бы вы?
Это все равно что нанимать команду разработчиков для создания одностраничного сайта булочной (хотя 90% требований можно закрыть конструктором на подобие вордпреса или тильды)
Во-первых, что вы понимаете под логин + пароль. Во-вторых, про SSL ни слова, т.к статья не про то. А описывать все вообще все аспекты авторизации одной статьи не хватит. В третьих, лучше объяснить как ребенку, но зато поймут точно все, чем надеется что все супер умные и знающие (зачем читать статью об авторизации, если ты и так знаешь как это делать)
Здесь наверное основной вопрос в том как уникально идентифицировать пользователя. Если злоумышленник сможет каким то образом достать и токены и подменить id устройства или еще что-то (например если мы добавим проверку по ip), то здесь затрудняюсь ответить, т.к а чем в действительности я как настоящий пользователь отличаюсь от злоумышленника (который теперь по сути имеет все что есть у меня). Здесь наверное нужно поиграться с временем протухания токенов.
На счет хранения токена в БД. А какой смысл ? Если токен воруют, то если его потом поменяют, то он просто не пройдет валидацию по сигнатуре
Если мы хотим одновременно быть онлайн с разных устройств, то можно иметь некий белый список устройств с которых можно авторизироваться. И чтобы добавить устройство в этот список, нужно подтвердить что вы имеете доступ к устройству с которого первый раз создавали профиль
Это размер приложения, который по сути представляет из себя Hello World. С более менее серьезными проектами, будет не так оптимистично. Не столько важно что 4мб, а то что больше чем в 4 раза.
1) Все верно, как я и написал. Blazor можно использовать в некоторых отдельных случаях. Возможно ваше приложение относится как раз таки к таковым.
2) Вы используете обертки, это автоматически означает что вы ограничены лишь тем функционалом, который в него заложили разработчики этой обертки. В 100 случаях из 100 обертка имеет более узкий функционал, чем оригинал, т.к оборачиваются наиболее популярные функции.
3) В случае с JS, вы правы он уступает C# в удобстве. Но работая с C# и TS я не могу сказать, что 2-ой сильно уступает. И если так то почему бы не выбрать более гибкий (а для web это так) инструмент.
Приведите пример преимуществ Blazor, которых НЕТ у React или Angular. Я лишь хочу сказать, что все преимущества которые есть у Blazor, есть и в других фреймворках, поэтому смысл переходить на него.
Например система типов там наверное покруче будет.
Эти преимущества взяты с официального сайта Microsoft, в скобках указаны мои размышления по поводу каждого из преимуществ. Поэтому тут я с вами согласен.
Если будет один дополнительный шаг перед деплоем
Так этот шаг и так есть. C# => WebAssembly
Вы все верно говорите, не могу понять, где в статье говориться обратное
Не совсем понял комментарий про "Если изменить на...". Зачем нам конвертировать C# в JS, если с помощью Blazor мы как раз хотим уйти от изпользования JS.
Не могу опровергнуть это или подтвердить. У нас не было вашего опыта, поэтому при выборе могли опираться только на данные из статей и обсуждений в различных блогах. Где как раз таки упоминались проблемы при росте нагрузки.
Да вы правы, .Net 6 уже действительно вышел и там есть атрибут [SupplyParameterFromQuery], как раз таки для этих целей. Но по скольку .Net 6 вышел совсем недавно, то высока вероятность, что еще мало кода написанного на этой версии. Поэтому у вас будет выбор, либо переиспользовать старый код и писать обертку для Query параметров. Либо использовать Net 6, но с нуля. Без переиспользования старого кода.
Я уважаю ваше желание жить в розовом мире и считать, что у нас что ни компания то обязательно Яндекс. Вот только я видел и работал с проектами не только в больших компаниях, но и с теми что приносят заказчики на фрилансе. И именно поэтому я с такой уверенностью вам говорю, что не все компании это Яндекс и не все делают все идеально. И даже не у всех самые новые технологии используются (но тут вы точно не поверите и скажите что я шучу)
Я действительно не совсем понимаю что вы имеете ввиду под парольной авторизацией (явно не то что я). Авторизация по логину + паролю, действительно почти (именно почти) нигде не используется. О чем в статье также написано. Тем не менее она использовалась раньше и поэтому нужно упомянуть о ней, чтобы было с чем сравнивать.
То что вы при авторизации вводите и логин и пароль это естественно. Здесь вопрос в том какие данные хранить в браузере для последующего взаимодействия. Можно ведь в localstorage сохранить логин и пароль и постоянно их на сервер отправлять. А при авторизации через gmail использется OAuth, который использует токены, а не просто логин и пароль
Слушайте, не спорю что статья не описывает все детали (ровно как и любая статья). Как минимум на практике не встречал статьи, которая отвечала бы на все вопросы.
Второй момент, да мы можем действительно хранить данные о времени жизни ни в самом токене, а в БД, но как вы и сказали это одна из реализаций (более сложная). Статья расчитана на людей, которые эту авторизацию хотят сделать сами у себя. Вот ответьте, если бы у вас были низкие знание о разработке, то какой из видов refresh токена выбрали бы вы?
Это все равно что нанимать команду разработчиков для создания одностраничного сайта булочной (хотя 90% требований можно закрыть конструктором на подобие вордпреса или тильды)
Во-первых, что вы понимаете под логин + пароль.
Во-вторых, про SSL ни слова, т.к статья не про то. А описывать все вообще все аспекты авторизации одной статьи не хватит.
В третьих, лучше объяснить как ребенку, но зато поймут точно все, чем надеется что все супер умные и знающие (зачем читать статью об авторизации, если ты и так знаешь как это делать)
Здесь наверное основной вопрос в том как уникально идентифицировать пользователя. Если злоумышленник сможет каким то образом достать и токены и подменить id устройства или еще что-то (например если мы добавим проверку по ip), то здесь затрудняюсь ответить, т.к а чем в действительности я как настоящий пользователь отличаюсь от злоумышленника (который теперь по сути имеет все что есть у меня). Здесь наверное нужно поиграться с временем протухания токенов.
На счет хранения токена в БД. А какой смысл ? Если токен воруют, то если его потом поменяют, то он просто не пройдет валидацию по сигнатуре
Если мы хотим одновременно быть онлайн с разных устройств, то можно иметь некий белый список устройств с которых можно авторизироваться. И чтобы добавить устройство в этот список, нужно подтвердить что вы имеете доступ к устройству с которого первый раз создавали профиль
Будем надеятся, что со временем будет еще лучше
Это размер приложения, который по сути представляет из себя Hello World. С более менее серьезными проектами, будет не так оптимистично. Не столько важно что 4мб, а то что больше чем в 4 раза.
1) Все верно, как я и написал. Blazor можно использовать в некоторых отдельных случаях. Возможно ваше приложение относится как раз таки к таковым.
2) Вы используете обертки, это автоматически означает что вы ограничены лишь тем функционалом, который в него заложили разработчики этой обертки. В 100 случаях из 100 обертка имеет более узкий функционал, чем оригинал, т.к оборачиваются наиболее популярные функции.
3) В случае с JS, вы правы он уступает C# в удобстве. Но работая с C# и TS я не могу сказать, что 2-ой сильно уступает. И если так то почему бы не выбрать более гибкий (а для web это так) инструмент.
Приведите пример преимуществ Blazor, которых НЕТ у React или Angular. Я лишь хочу сказать, что все преимущества которые есть у Blazor, есть и в других фреймворках, поэтому смысл переходить на него.
Вы все верно говорите, не могу понять, где в статье говориться обратное
Не совсем понял комментарий про "Если изменить на...". Зачем нам конвертировать C# в JS, если с помощью Blazor мы как раз хотим уйти от изпользования JS.
Не могу опровергнуть это или подтвердить. У нас не было вашего опыта, поэтому при выборе могли опираться только на данные из статей и обсуждений в различных блогах. Где как раз таки упоминались проблемы при росте нагрузки.
Да вы правы, .Net 6 уже действительно вышел и там есть атрибут [SupplyParameterFromQuery], как раз таки для этих целей. Но по скольку .Net 6 вышел совсем недавно, то высока вероятность, что еще мало кода написанного на этой версии. Поэтому у вас будет выбор, либо переиспользовать старый код и писать обертку для Query параметров. Либо использовать Net 6, но с нуля. Без переиспользования старого кода.