WinForms и WPF ровно так и работают. Asp.net forms тоже пытались в "накидать", но очень быстро ушли от этого (и слава богу). Хотя при желании можно нарыть визуальный конструктор клиентской части для web.
Выше уже про это писали, но всё равно скажу что универсальные решения из коробки далеко не всегда подходят. На сколь-нибудь сложных проектах либо ищешь стороннее решение, либо пишешь с нуля.
Млин, текст новости составлен так, что якобы в первую очередь будут оценивать дизайн и похожесть, а не нарушает ли ресурс правила или нет. Если так будет и на практике -- чебурнет будет на шаг ближе.
Забей в гугл "верификация третьей стороной в телеграме", должно выдать ссылку на их доку по этому вопросу. Я тоже сначала прифигел мол "ого, прям настолько сотрудничают", но по ходу у Паши Дурова работают толковые креативщики и предусмотрели занятный функционал.
Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).
В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.
На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.
С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.
Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.
Ну и ещё несколько весёлых вещей:
требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.
пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.
порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить
если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)
Не особо понял про константы и длл. Вся "прелесть" констант в том что компилятор явно прописывает значения в коде без каких либо переменных. И это приводит к "нежданчикам" когда в либе сначала одно значение, на его основе компилируется код использующий константу, далее либа заменяется на новую путём простой замены файла с иным значением и вуаля -- программа работает неправильно. Поэтому выносить в константы всё подряд не ок.
Я не знаком с java, поэтому нубский вопрос -- без throws в описании метода можно вызвать throw? Если да, то выглядит как прикольная фича, но в c# можно указать исключения в summary.
Ну и пример с callback был к тому, что на момент компиляции мы не можем знать всех исключений, которые прилетят из метода.
Я не уверен что все примеры являются альтернативой шифрованию, и решаемых им задач. Больше похоже на некие наброски в духе "шифрование не прячет данные, а вот стегонаграфия это делает". Круто конечно, но безопасности обмена данными между серверами это не особо добавляет, да и как правило там не стоит задача прям ныкать этот трафик.
Я слабо представляю как это должно выглядеть. Самое банальное -- метод принимает делегат обратного вызова, который может выкинуть своё уникальное исключение.
Ну, стоит хоть немного понимать что ретранслируешь. Пример с IReadOnlyList ну прям вообще ни о чём (мягко говоря) и кажись даже у новичков нет проблем с пониманием как работает приведение типов. Выше уже упоминали что interface != class, и такое явное приведение допускается исходя из логики что разработчику известно больше, чем компилятору. Более того, со временем в C# добавили такую возможность как после проверки на тип сразу привести к нему в одну строку, например if(variable is MyType myType) { /* использование переменной myType */ } что как бы намекает.
По второму примеру вообще мимо: показано явное приведение, которое явно задекларировано в ЯП, повсеместно используется и при этом автор говорит что это нехорошо. Ну ок, автору виднее. =)
Хотя тут вся статья в духе Wat, чисто посмеяться -- норм. Но на практике конкретно эти вещи не шибко мешают, а вот например непонимания как работают константы может подкинуть реальных сюрпризов на практике.
Первая мысль при прочтении: "и это всё?" Ну т.е. "оно децентрализировано и работает". Окей, а как? Почему имеет смысл выбрать этот вариант, а не скажем дублировать бэкапы на 4-5 классических сервисах? По факту после прочтения статьи нужно идти и разбираться в основах IPFS.
Отдельно раздражает кликбейтный заголовок и наличие в тегах "Веб-разработка + DevOps" которых по факту тут нет.
Они кажись ещё год назад грозились всё это добро отключить. Так что в этой новости для меня нове скорее что оно до сих пор работало. А, ну и вездесущий ИИ, куда же без него... Лучше бы таки вернули возможность в системном календаре видить запланированные задачи, как это было в старом Mail.
можно ещё так
if(preson?.Age > 18)WinForms и WPF ровно так и работают. Asp.net forms тоже пытались в "накидать", но очень быстро ушли от этого (и слава богу). Хотя при желании можно нарыть визуальный конструктор клиентской части для web.
Выше уже про это писали, но всё равно скажу что универсальные решения из коробки далеко не всегда подходят. На сколь-нибудь сложных проектах либо ищешь стороннее решение, либо пишешь с нуля.
Всегда думал что .net в первую очередь конкурирует с java
Млин, текст новости составлен так, что якобы в первую очередь будут оценивать дизайн и похожесть, а не нарушает ли ресурс правила или нет. Если так будет и на практике -- чебурнет будет на шаг ближе.
CrowdStrike -- это не тот, из-за которого лежали все терминалы на аэропортах?
Можно небольшое уточнение: просили расшарить экран и просто подсказывать что к чему или дать прям удалённый доступ?
Забей в гугл "верификация третьей стороной в телеграме", должно выдать ссылку на их доку по этому вопросу. Я тоже сначала прифигел мол "ого, прям настолько сотрудничают", но по ходу у Паши Дурова работают толковые креативщики и предусмотрели занятный функционал.
Ну, вкинуть аргументы почему статья не очень всё же лучше. Так читающий школьник поймёт почему это плохо.
Только SS+
Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).
В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.
На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.
С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.
Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.
Ну и ещё несколько весёлых вещей:
требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.
пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.
порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить
если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)
Не особо понял про константы и длл. Вся "прелесть" констант в том что компилятор явно прописывает значения в коде без каких либо переменных. И это приводит к "нежданчикам" когда в либе сначала одно значение, на его основе компилируется код использующий константу, далее либа заменяется на новую путём простой замены файла с иным значением и вуаля -- программа работает неправильно. Поэтому выносить в константы всё подряд не ок.
Я не знаком с java, поэтому нубский вопрос -- без throws в описании метода можно вызвать throw? Если да, то выглядит как прикольная фича, но в c# можно указать исключения в summary.
Ну и пример с callback был к тому, что на момент компиляции мы не можем знать всех исключений, которые прилетят из метода.
Я не уверен что все примеры являются альтернативой шифрованию, и решаемых им задач. Больше похоже на некие наброски в духе "шифрование не прячет данные, а вот стегонаграфия это делает". Круто конечно, но безопасности обмена данными между серверами это не особо добавляет, да и как правило там не стоит задача прям ныкать этот трафик.
Я слабо представляю как это должно выглядеть. Самое банальное -- метод принимает делегат обратного вызова, который может выкинуть своё уникальное исключение.
Ну, стоит хоть немного понимать что ретранслируешь. Пример с IReadOnlyList ну прям вообще ни о чём (мягко говоря) и кажись даже у новичков нет проблем с пониманием как работает приведение типов. Выше уже упоминали что interface != class, и такое явное приведение допускается исходя из логики что разработчику известно больше, чем компилятору. Более того, со временем в C# добавили такую возможность как после проверки на тип сразу привести к нему в одну строку, например
if(variable is MyType myType) { /* использование переменной myType */ }что как бы намекает.По второму примеру вообще мимо: показано явное приведение, которое явно задекларировано в ЯП, повсеместно используется и при этом автор говорит что это нехорошо. Ну ок, автору виднее. =)
Хотя тут вся статья в духе Wat, чисто посмеяться -- норм. Но на практике конкретно эти вещи не шибко мешают, а вот например непонимания как работают константы может подкинуть реальных сюрпризов на практике.
Ради понимания: а почему на данный момент сроки отзыва сертификата довольно существены?
Первая мысль при прочтении: "и это всё?" Ну т.е. "оно децентрализировано и работает". Окей, а как? Почему имеет смысл выбрать этот вариант, а не скажем дублировать бэкапы на 4-5 классических сервисах? По факту после прочтения статьи нужно идти и разбираться в основах IPFS.
Отдельно раздражает кликбейтный заголовок и наличие в тегах "Веб-разработка + DevOps" которых по факту тут нет.
Они кажись ещё год назад грозились всё это добро отключить. Так что в этой новости для меня нове скорее что оно до сих пор работало. А, ну и вездесущий ИИ, куда же без него... Лучше бы таки вернули возможность в системном календаре видить запланированные задачи, как это было в старом Mail.