Да, тогда, конечно, только решение 1andy: использовать статический класс Bundle той же библиотеки (using SquishIt.Framework).
За сегодняшний день выяснилось, что это на порядок удобнее:
— можно сделать отдельные файлы (например, один общий объединенно-минифицированный файл для всех страниц в главном layout'е и еще один на конкретной странице);
— можно оставить , если использовать функцию .ForceRelease();
— наконец, файлы складываются в общий в той последовательности, в которой указываешь, а не снизу вверх.
Ваша правда, конечно.
Но всё же это существенно дольше, чем простой перебор по словарю: например, подстановка одной прописной буквы в 6-значный пароль увеличивает время поиска в семь раз. А если неизвестное количество прописных букв, то еще больше. А если добавить цифры… Ну и так далее.
Ну Microsoft вообще не скупится на pdb-шки к своим проектам: Microsoft Symbol Server.
Хотя и интересно, почему он там сразу с символами. Неужели debug-версию положили? :)
И еще по поводу того, что «сразу становится видно, что длина пароля намного важнее его сложности». Так-то оно так, но вот любопытные цифры с того же howsecureismypassword.net: securepassword - About 8 thousand years
Securepassword - About 133 million years
Secure passwrd - About 10 billion years
Secur passw0rd - About 66 billion years
Secur pas_w0rd - About 715 billion years
То есть понятно, что с ростом количества знаков сложность перебора растет быстрее, чем с увеличением сложности, но всё-таки очевидно, что добавление группы символов в пароль на порядок — увеличивает время подбора.
Плюс исключается возможность перебора по словарю даже если просто добавить заглавную букву в середину слова.
Нормальная такая ситуация: когда человек живет в другой языковой среде, он начинает вставлять иностранные слова в родную речь, когда навскидку не может вспомнить слово на своем языке.
Причем это происходит так непроизвольно, что человек сам не осознает, что в речь вкрались лоеры.
А в случае с почтой — одно поле вместо трех. Текст сообщения.
Я же указал, какие вижу минусы. На мой взгляд, вполне очевидные.
Вы указали минусы mailto — для определенных ситуаций тоже явные.
При этом я не говорю, что mailto — единственное правильное решение. Но пока есть недостатки в отправке через форму, этот способ явно имеет право на жизнь.
Хороший и правильный взгляд, но зачем же так радикально.
Тот же mailto комментом выше я предлагал собирать JS-ом, дабы защититься от парсеров.
Да, защищаться можно по-разному, и в каждом случае будут свои плюсы и минусы.
Гифка — сразу нет, изначальный смысл моего сообщения был в том, что пользователю должно быть удобно. Поэтому минимум полей, минимум капчи и прочих механизмов, и, как следствие, минимум действий от пользователя.
Вот конкретные минусы, которые побудили меня проголосовать за mailto:
— Допустим, вероятность спама у нас одинаковая при одинаковых усилиях, приложенных для защиты от него. Причем она ненулевая, учитывая индусов, школьников, следующего поколения спам-ботов и ботов, написанных специально для вашего сайта.
В таком случае при mailto спам будет получен с левого спамерского ящика и скорее всего отфильтруется. В случае с формой он будет получен с какого-нибудь feedback@yoursite.com, с которого постоянно приходят полезные письма. И опять же почти наверняка попадет во входящие. Добавить в спам письмо со своего ящика я не решусь, не зная, какие точно механизмы у антиспама.
— Обратная ситуация. Не так давно был конкретный пример использования мной формы обратной связи. Это был маленький интернет-магазинчик, я спросил, сколько будет стоить доставка в мой город и вообще возможно ли это.
Недели через две я случайно заглянул в папку «спам» и обнаружил ответ от них. Хотя конечно думал, что про меня там уже забыли. Вероятность, что письмо-Re попадет в папку спам, как мне видится, равна нулю, потому что gmail объединяет их в цепочки.
При этом Вам удалось меня убедить, что есть и другие способы защиты от спама в формах отправки помимо капчи. Тем не менее, в случае необходимости обратной связи я по-прежнему предпочел бы mailto, даже несмотря на то, что знаю JS.
Ну можно по крайней мере JS-ом собирать ссылки, чтоб в тексте страницы их не было.
Согласен с Вами, конечно, что это не панацея, но по крайней мере здесь не доставляется дополнительных неудобств пользователю.
И в случае спама из формы, он посыпется с вашего служебного ящика, который для антиспама будет выглядеть как хороший ящик, с которого вы постоянно получаете почту.
Проголосовал за mailto, потому что светлую идею формы отправки с сайта обязательно изгадят спам-боты. Придется добавлять капчу, а это уже некрасиво.
Плюс для обратной связи надо добавлять поле ввода e-mail. Имхо, тоже минус.
@Html.Raw(Bundle...)
За сегодняшний день выяснилось, что это на порядок удобнее:
— можно сделать отдельные файлы (например, один общий объединенно-минифицированный файл для всех страниц в главном layout'е и еще один на конкретной странице);
— можно оставить , если использовать функцию .ForceRelease();
— наконец, файлы складываются в общий в той последовательности, в которой указываешь, а не снизу вверх.
Но если это указание на миллион if-ов в коде, Вы несомненно правы.
Вызывает восхищение такой подход к решению проблем.
И, кстати, к написанию статей тоже.
Но всё же это существенно дольше, чем простой перебор по словарю: например, подстановка одной прописной буквы в 6-значный пароль увеличивает время поиска в семь раз. А если неизвестное количество прописных букв, то еще больше. А если добавить цифры… Ну и так далее.
Хотя и интересно, почему он там сразу с символами. Неужели debug-версию положили? :)
Вот фигня, надо срочно менять.
И еще по поводу того, что «сразу становится видно, что длина пароля намного важнее его сложности». Так-то оно так, но вот любопытные цифры с того же howsecureismypassword.net:
securepassword - About 8 thousand years
Securepassword - About 133 million years
Secure passwrd - About 10 billion years
Secur passw0rd - About 66 billion years
Secur pas_w0rd - About 715 billion years
То есть понятно, что с ростом количества знаков сложность перебора растет быстрее, чем с увеличением сложности, но всё-таки очевидно, что добавление группы символов в пароль на порядок — увеличивает время подбора.
Плюс исключается возможность перебора по словарю даже если просто добавить заглавную букву в середину слова.
Причем это происходит так непроизвольно, что человек сам не осознает, что в речь вкрались лоеры.
Я же указал, какие вижу минусы. На мой взгляд, вполне очевидные.
Вы указали минусы mailto — для определенных ситуаций тоже явные.
При этом я не говорю, что mailto — единственное правильное решение. Но пока есть недостатки в отправке через форму, этот способ явно имеет право на жизнь.
Тот же mailto комментом выше я предлагал собирать JS-ом, дабы защититься от парсеров.
Да, защищаться можно по-разному, и в каждом случае будут свои плюсы и минусы.
Гифка — сразу нет, изначальный смысл моего сообщения был в том, что пользователю должно быть удобно. Поэтому минимум полей, минимум капчи и прочих механизмов, и, как следствие, минимум действий от пользователя.
Вот конкретные минусы, которые побудили меня проголосовать за mailto:
— Допустим, вероятность спама у нас одинаковая при одинаковых усилиях, приложенных для защиты от него. Причем она ненулевая, учитывая индусов, школьников, следующего поколения спам-ботов и ботов, написанных специально для вашего сайта.
В таком случае при mailto спам будет получен с левого спамерского ящика и скорее всего отфильтруется. В случае с формой он будет получен с какого-нибудь feedback@yoursite.com, с которого постоянно приходят полезные письма. И опять же почти наверняка попадет во входящие. Добавить в спам письмо со своего ящика я не решусь, не зная, какие точно механизмы у антиспама.
— Обратная ситуация. Не так давно был конкретный пример использования мной формы обратной связи. Это был маленький интернет-магазинчик, я спросил, сколько будет стоить доставка в мой город и вообще возможно ли это.
Недели через две я случайно заглянул в папку «спам» и обнаружил ответ от них. Хотя конечно думал, что про меня там уже забыли. Вероятность, что письмо-Re попадет в папку спам, как мне видится, равна нулю, потому что gmail объединяет их в цепочки.
При этом Вам удалось меня убедить, что есть и другие способы защиты от спама в формах отправки помимо капчи. Тем не менее, в случае необходимости обратной связи я по-прежнему предпочел бы mailto, даже несмотря на то, что знаю JS.
Согласен с Вами, конечно, что это не панацея, но по крайней мере здесь не доставляется дополнительных неудобств пользователю.
И в случае спама из формы, он посыпется с вашего служебного ящика, который для антиспама будет выглядеть как хороший ящик, с которого вы постоянно получаете почту.
Плюс для обратной связи надо добавлять поле ввода e-mail. Имхо, тоже минус.