Почему люди не используют <CFLOGIN>?
Гораздо проще, если вместо этого использовать вложенный цикл
char a1[] = {'R', 'A', 'D', 'A', 'K'};
boolean isPalindrome=true;
for (int i = 0; i < a1.length-1; i++) {
for (int j = a1.length-1; j >=0; j--) {
if(a1[i]==a1[j])
isPalindrome=true;
else
isPalindrome=false;
}
}
System.out.println(isPalindrome);
5 ответов
Я использую cflogin все время, и он работает отлично. Это может быть немного хитро для получения работы путем, Вам нравится, но преимущества огромны. Способность точно настроить Ваше приложение с пользовательскими ролями заботится об объеме моей основанной на правах настройки. Раньше были некоторые проблемы с управлением сеансами, которое мешало работать с. Включение j2ee сессии, кажется, заставляет большинство тех проблем уйти.
Некоторые популярные платформы не совместимы с cflogin, так, чтобы могла бы быть одна причина, Вы не видите многое из него. Они имеют тенденцию иметь свой собственный подход к обеспечению функций приложения.
Я думаю, что много людей расстроено им, потому что это является немного изворотливым, и они разочаровываются в нем. У других есть более сложные потребности безопасности, которые не обращены полностью cflogin, таким образом, они завершают запись их собственной системы. А именно, нет простого способа иметь дело с правами активом содержания.
Единственная проблема, которую я имел, с ролями в CF8. Это блестяще реализовано и немного жестокое, что не работает, как это вполне должно. Возможно, в CF9.
В любом случае создание Вашей собственной основанной на ролях системы (присваивают пользователю переменную сеанса со списком разделенных запятой значений уровней доступа, которые система может проверить по) не слишком трудно сделать, и я преобладал над ним.
Одна хорошая вещь о cfLogin, который, вероятно, все еще стоит использовать, состоит в том, как это набрасывается на монитор Сервера для наблюдения, сколько людей зарегистрировано и т.д.
Точка выше об использовании jsession верна, это стоит сделать во всех cf приложениях. Одна из лучших вещей, до которых я перетащил меня, получает работу, как я хотел это.
CFLogin не используется по 3 причинам.
Во-первых, это немного раздражительно, немного странно, и не работает, сколько думало бы. Вы помещаете некоторый код здесь, и если пользователь не зарегистрирован, он выполняет его... это просто нечетно, Вы знаете? Не помогло, что были некоторые ошибки вначале, также.
Во-вторых, в то время как это имеет основные необходимые средства защиты для веб-приложения, это не идет дальше. Вы не можете действительно расширить его легко. Кто должен сказать, что это - то, как все хотят это?
В-третьих, и наиболее реалистично, это - потому что люди уже решили ту проблему. Проблемная область обеспечения приложения, аутентификация и авторизация продумывалась в сообществе достаточно долго, и большинство людей знает, как просто сделать это. CFLogin переосмысливает дверь. Это слишком мало, слишком поздно.
Теперь, но это вовсе не значит то, что никто не использует его. Я лично использовал его несколько раз с основным успехом, но никакой причиной позвонить в звонок. Для большинства моих приложений имеет больше смысла не использовать CFLogin. Проблемные области являются этим путем или что, и CFLogin не всегда решает его самым интеллектуальным способом.
Действительно имейте в виду, что CFLOGIN имеет выгоду с Основным Автором HTTP, где он может продолжить отправлять свой UserID и Пароль даже после вызова CFLOGOUT.
Я знаю, что это отогнало некоторых опытных пользователей от него.
Вот выборка от LiveDocs
Внимание: При использовании основанной на веб-сервере аутентификации или какой-либо аутентификации формы, которая использует Основной заголовок Авторизации HTTP, браузер продолжает отправлять информацию аутентификации в приложение, пока пользователь не закрывает браузер, или в некоторых случаях, все открытые окна браузера. В результате после того, как пользователь выходит из системы, и Ваше приложение использует тег cflogout, пока завершения браузера, cflogin структура в теге cflogin не будет содержать UserID вышедшего из системы пользователя и пароль. Если пользователь выходит из системы и не закрывает браузер, другой пользователь мог бы получить доступ к страницам с входом в систему первого пользователя.
В моем случае (предполагают для некоторых других людей также) главная причина перемещается с другой платформы, скажите PHP. Я подразумеваю, что уже получил некоторое знание и привычки в разработке ACL и начал использовать их в CF.
Я знаю, как сделать это удобным для пользователя, гибкого для разработчика, и защитить и не должен действительно переключаться на cflogin.
Иногда то же происходит с другим материалом, скажите в большинстве случаев, что я предпочитаю реализовывать клиентскую проверку с помощью собственного JS вместо того, чтобы использовать cfform/cfinput.