Проблема не у одного.
Сами разработчики о проблеме знают, но отпираются — мол, проблема не у них, а у swing.
Для себя решил установкой альтернативного таск-свитчера.
Не сталкивался при работе в нем с такими крупными файлами PHP, но вот при попытке открыть в нем огромный javascript он сначала сам предупредил что при открытии такого большого возможны проблемы. После чего честно рухнул :)
Кстати, предупреждение об этом у него весьма анекдотично:
Если сообщество со сформировавшимися правилами и традициями — то пользовательского соглашения не нужно. Те, кто туда попадают не случайно — уже знают правила. А случайные прохожие такому сообществу особо и не нужны.
А если просто по-человечески подойти к вопросу, то автор определенно не прав. Это все равно что зайти в случайную квартиру и с порога сказать: «А почему вы меня впустили, а правила поведения в вашей квартире не объяснили?!». Да вас в эту квартиру и не звал никто :)
С другой стороны правила действительно нужны, хотя бы для того что бы отгородить себя от таких товарищей.
Может быть все дело в том, что вы очень сильно себя любите? Яндекс следит за вами. А вебальта вот пока не знает.
Для более корректного сравнения стоит сначала заставить Яндекс забыть о вас.
Да и то, о корректности такого сравнения говорить можно с трудом.
В принципе, согласен, прочитать пароль во время ввода с экрана гораздо проще, чем с клавиатуры. Но и с клавиатуры человеком с хорошей зрительной памятью (+обладающем слепым набором) пароль считается просто по движениям ваших пальцев :)
> пользователь постоянно видит в течение какого-то времени последнюю введённую букву
А теперь попробуй вводить пароль БЫСТРО :)
Если за таймаут успеть набрать несколько букв, то последнюю букву видно не будет.
Т.е. таймаут сработавший после первого нажатия не сбрасывается при следующем.
А ведь вероятность ошибки возрастает именно при быстром «слепом» наборе :)
Я бы сделал так — набранный символ исчезает строго через заданный интервал. При нажатии на последующую кнопку первый символ все равно остается видимым, пока не подошло его время исчезнуть.
И еще:
2. Если jscript отключен, то пользователь видит свой пароль в чистом виде. Не говоря уже о том, что получить набранный пароль можно лишь через вызов jscript, который у пользователя отключен и войти он не сможет.
3. Все та же необходимость вызова функции для получения пароля. Для формы необходимо реализовывать еще и .submit, что бы подставить реальный пароль, а не звезды содержащиеся в контроле.
Для обоих этих пунктов верно то, что НЕОБХОДИМО оставить возможность отправки пароля по обычному submit-у, ничем не переопределенному.
И в этом случае я бы поступил так: при вызове .iPasswordBox() создается новый инпут, в котором и будут рисоваться звезды, а старый делается скрытым. В него синхронно грузится введенный пароль.
И последнее. На мобильных платформах эта функция нужна из-за предикативного ввода. Сам компонент отвечающий за отображения строки с паролем может не знать вводите вы на полноценной qwerty или же тыкаете по 3 раза на одну и ту же кнопку, поэтому и отображается всегда.
А еще лучше, помимо X-Accel-Redirect использовать mod_upload.
X-Accel-Redirect позволит считать статистику при скачивании (ну или другие действия, по вкусу), при этом обезопасить себя от DDOS-ов путем скачивания больших файлов.
mod_upload наоборот, для того что бы обезопасить себя от DDOS-ов путем закачивания файлов.
И т.к. за отдачу файлов будет отвечать frontend, то о большей части сказанного в этой статье можно забыть.
Сами разработчики о проблеме знают, но отпираются — мол, проблема не у них, а у swing.
Для себя решил установкой альтернативного таск-свитчера.
Кстати, предупреждение об этом у него весьма анекдотично:
Почему нет варианта НЛОS?
В чужой монастырь со своим уставом не суйся.
Если сообщество со сформировавшимися правилами и традициями — то пользовательского соглашения не нужно. Те, кто туда попадают не случайно — уже знают правила. А случайные прохожие такому сообществу особо и не нужны.
А если просто по-человечески подойти к вопросу, то автор определенно не прав. Это все равно что зайти в случайную квартиру и с порога сказать: «А почему вы меня впустили, а правила поведения в вашей квартире не объяснили?!». Да вас в эту квартиру и не звал никто :)
С другой стороны правила действительно нужны, хотя бы для того что бы отгородить себя от таких товарищей.
Может быть все дело в том, что вы очень сильно себя любите? Яндекс следит за вами. А вебальта вот пока не знает.
Для более корректного сравнения стоит сначала заставить Яндекс забыть о вас.
Да и то, о корректности такого сравнения говорить можно с трудом.
Что бы потом отдельным личностям не выдавало сообщений вроде «Phishing Site Blocked» — сложно :)
А платных полно. Но все зависит от того, что вам нужно. Если просто вывешивать html-ки, то достаточно выбирать исходя из цены :)
Вот чего-чего, а этого делать нельзя ни в коем случае.
Кто мешает при замене введенного символа на звездочку проверять есть ли еще этот символ вообще?
В принципе, согласен, прочитать пароль во время ввода с экрана гораздо проще, чем с клавиатуры. Но и с клавиатуры человеком с хорошей зрительной памятью (+обладающем слепым набором) пароль считается просто по движениям ваших пальцев :)
Отличное решение, спасибо :)
А теперь попробуй вводить пароль БЫСТРО :)
Если за таймаут успеть набрать несколько букв, то последнюю букву видно не будет.
Т.е. таймаут сработавший после первого нажатия не сбрасывается при следующем.
А ведь вероятность ошибки возрастает именно при быстром «слепом» наборе :)
Я бы сделал так — набранный символ исчезает строго через заданный интервал. При нажатии на последующую кнопку первый символ все равно остается видимым, пока не подошло его время исчезнуть.
И еще:
2. Если jscript отключен, то пользователь видит свой пароль в чистом виде. Не говоря уже о том, что получить набранный пароль можно лишь через вызов jscript, который у пользователя отключен и войти он не сможет.
3. Все та же необходимость вызова функции для получения пароля. Для формы необходимо реализовывать еще и .submit, что бы подставить реальный пароль, а не звезды содержащиеся в контроле.
Для обоих этих пунктов верно то, что НЕОБХОДИМО оставить возможность отправки пароля по обычному submit-у, ничем не переопределенному.
И в этом случае я бы поступил так: при вызове .iPasswordBox() создается новый инпут, в котором и будут рисоваться звезды, а старый делается скрытым. В него синхронно грузится введенный пароль.
И последнее. На мобильных платформах эта функция нужна из-за предикативного ввода. Сам компонент отвечающий за отображения строки с паролем может не знать вводите вы на полноценной qwerty или же тыкаете по 3 раза на одну и ту же кнопку, поэтому и отображается всегда.
X-Accel-Redirect позволит считать статистику при скачивании (ну или другие действия, по вкусу), при этом обезопасить себя от DDOS-ов путем скачивания больших файлов.
mod_upload наоборот, для того что бы обезопасить себя от DDOS-ов путем закачивания файлов.
И т.к. за отдачу файлов будет отвечать frontend, то о большей части сказанного в этой статье можно забыть.
P.S. enartemy, благодарю за инвайт :)