По инструментам то понятно. Но вокал - там же нот практически (может и совсем) нет. Да и в этом жанре все эти автотюны обычно порицаются, ценится живое исполнение.
Я сам не ожидал, поскольку требование очень странное.
Да не очень то странное. Я как-то забрёл в этот Я.Музыка и глянул популярное. Само собой - почти всё проходное барахло, и всё оно меньше 3-х минут. То ли из авторов большее просто не выдавливается, либо их не сильно притязательная аудитория дольше не выдерживает. По моему опыту, серьёзные произведения обычно около 4-х минут и более. В общем, вполне рабочий критерий.
Если бы не было разницы, то у музыкантов не было бы фанатов. Тех, что ходят на все концерты, скупают мерч, диски, винил, плакаты, подписываются на них в соцсетях и всё такое прочее.
А почему вы не хотите принят то, что для кого-то действительно важно именно от человека? Что для некоторых музыка - это не просто утилитарная вещь, а способ социальной коммуникации и самовыражения. Им просто не интересно что может сгенерировать какая-то программа, им интересно что хотят и могут придумать и создать такие же люди, как они. Им интересны и сами личности, и их творчество. Какой же в этом луддизм?
По описанию похоже на OAuth (или OpenID), то, что уже и так работает у VK - вход по VK ID через приложение VK.
И 4-5 пункты тут не работают.
Это вход на одном сайте через подобную кнопку.
Очевидно, приложение не видит с какого сайта его вызвали. Что ожидаемо, ибо заголовок Referer крайне не надёжные источник. Да и напрямую из браузера такие вызовы, вроде как, не делаются.
К тому же, в таком случае отправлять коды через этот же мессенджер-авторизатор уже не имеет смысла.
Проблема с этими кодами в том, что по сути, фактор владения в некоторой степени превращается в фактор знания. Что сильно снижает эффективность защиты. Первым очень сложно "поделиться", а вторым - крайне просто (особенно когда это короткие цифровые коды).
Но тут, как обычно, сложный вопрос удобства. Хорошая защита обычно очень неудобна для большинства пользователей.
В онлайне это более возможно - приложение-авторизатор можно научить понимать, что это не сайт госуслуг код просит, а сайт мошенников
Не могу представить каким это образом возможно. Сайт ведь запрашивает в браузере, это отдельное приложение, между ними нет никакой связи. Если только не ходить на сайты только через это же приложение-авторизатор-браузер. Но это сомнительное решение.
От фишинга в любом случае надо защищать. И это не так просто.
Есть только ТОТП, который все мошенники так активно и выциганивают по телефонам
Следует различать OTP от TOTP (time-based one-time password). Последний как раз таки вряд ли смогут выциганивать, ибо телефон там не используется. Даже если они узнают телефон и позвонят, интересно, что нужно сказать, что бы жертва назвала этот код?
Но там ведь используется одно и то же подключение (сессия). И все запросы осуществляются в рамках этой сессии. Я, может, что-то не так понимаю, но stateless означает, что каждый запрос хранит всю информацию для его обработки и изолирован от других запросов. То есть, разные запросы могут обрабатываться разными экземплярами сервера. Что позволяет осуществлять балансировку запросов при горизонтальном масштабировании. А как это реализовать с WebSocket? Он же работает в рамках одного HTTP запроса (с переключением протокола). И сессия привязана к одному серверу.
То, что в нём на транспортном уровне есть постоянное соединение, не означает наличия состояние
А как же аутентификация? В каждом запросе отправляется jwt (или что-то подобное)?
Даже на транспортном уровне нужно разделять 401 от 403. В первом случае значит, что нужно пройти определённую процедуру и можно повторить этот запрос. Если, например, настроена http basic authentication, то в ответе будет соответствующий заголовок, тогда браузер запросит логин и пароль, и повторит запрос. Могут быть и другие способы. И они могут осуществляться и веб-сервером без участия приложения.
А 403 говорит что эта операция клиенту с этими учётными данными запрещена, и повторять запрос не надо.
По инструментам то понятно. Но вокал - там же нот практически (может и совсем) нет. Да и в этом жанре все эти автотюны обычно порицаются, ценится живое исполнение.
Насчёт абсолютно везде слабо верится. Сомневаюсь, что какие-нибудь Lorna Shore его используют. Можно ли такое затюнить вообще?
Когда это точечно местами чуть подтянуто - можно понять. Но когда вся партия сильно натянута - это уже издевательство.
Да не очень то странное. Я как-то забрёл в этот Я.Музыка и глянул популярное. Само собой - почти всё проходное барахло, и всё оно меньше 3-х минут. То ли из авторов большее просто не выдавливается, либо их не сильно притязательная аудитория дольше не выдерживает. По моему опыту, серьёзные произведения обычно около 4-х минут и более. В общем, вполне рабочий критерий.
Если бы не было разницы, то у музыкантов не было бы фанатов. Тех, что ходят на все концерты, скупают мерч, диски, винил, плакаты, подписываются на них в соцсетях и всё такое прочее.
Музыку надо оценивать как хочется - это личный выбор каждого.
Примерно как
rand()отличается отx*2Мне не понятно почему желание людей знать, творчество это или продукт автоматизации, вы называете луддизмом.
А почему вы не хотите принят то, что для кого-то действительно важно именно от человека? Что для некоторых музыка - это не просто утилитарная вещь, а способ социальной коммуникации и самовыражения. Им просто не интересно что может сгенерировать какая-то программа, им интересно что хотят и могут придумать и создать такие же люди, как они. Им интересны и сами личности, и их творчество. Какой же в этом луддизм?
И как же вы это сравнивали?
При чём тут autofill? Форма ввода на компе мошенника.
Но тут речь про конкретный случай - когда мошенник инициирует отправку кода (форма ввода у него на компе), и просит жертву продиктовать его.
По описанию похоже на OAuth (или OpenID), то, что уже и так работает у VK - вход по VK ID через приложение VK.
И 4-5 пункты тут не работают.
Очевидно, приложение не видит с какого сайта его вызвали. Что ожидаемо, ибо заголовок Referer крайне не надёжные источник. Да и напрямую из браузера такие вызовы, вроде как, не делаются.
К тому же, в таком случае отправлять коды через этот же мессенджер-авторизатор уже не имеет смысла.
Проблема с этими кодами в том, что по сути, фактор владения в некоторой степени превращается в фактор знания. Что сильно снижает эффективность защиты. Первым очень сложно "поделиться", а вторым - крайне просто (особенно когда это короткие цифровые коды).
Но тут, как обычно, сложный вопрос удобства. Хорошая защита обычно очень неудобна для большинства пользователей.
Не могу представить каким это образом возможно. Сайт ведь запрашивает в браузере, это отдельное приложение, между ними нет никакой связи. Если только не ходить на сайты только через это же приложение-авторизатор-браузер. Но это сомнительное решение.
От фишинга в любом случае надо защищать. И это не так просто.
Вот только TOTP сам собой не всплывёт в телефоне. Это нужно открывать специальную программу и в ней смотреть код к конкретной учётке.
И поэтому его самого так же надо защищать.
Следует различать OTP от TOTP (time-based one-time password). Последний как раз таки вряд ли смогут выциганивать, ибо телефон там не используется. Даже если они узнают телефон и позвонят, интересно, что нужно сказать, что бы жертва назвала этот код?
Или тыкнув галочку. Хотя, и без этого спокойно скачивается, просто открывается вкладка для доната.
Но там ведь используется одно и то же подключение (сессия). И все запросы осуществляются в рамках этой сессии. Я, может, что-то не так понимаю, но stateless означает, что каждый запрос хранит всю информацию для его обработки и изолирован от других запросов. То есть, разные запросы могут обрабатываться разными экземплярами сервера. Что позволяет осуществлять балансировку запросов при горизонтальном масштабировании. А как это реализовать с WebSocket? Он же работает в рамках одного HTTP запроса (с переключением протокола). И сессия привязана к одному серверу.
А как же аутентификация? В каждом запросе отправляется jwt (или что-то подобное)?
Ну это уже сильно отходит от изначального концепта REST. Если не ошибаюсь, он подразумевает stateless протокол. А WebSocket явно не такой.
Даже на транспортном уровне нужно разделять 401 от 403. В первом случае значит, что нужно пройти определённую процедуру и можно повторить этот запрос. Если, например, настроена http basic authentication, то в ответе будет соответствующий заголовок, тогда браузер запросит логин и пароль, и повторит запрос. Могут быть и другие способы. И они могут осуществляться и веб-сервером без участия приложения.
А 403 говорит что эта операция клиенту с этими учётными данными запрещена, и повторять запрос не надо.
Не только транспортного. В приложении он тоже доступен. Зачем от него там отказываться?
А работать оно будет? Браузер закэширует 500-й? Это было очень не разумно.
Так его придумывали именно под HTTP. На какой ещё протокол его можно применить?