http://findevelop.blogspot.ru/2013/10/web-spring-security-100.html
мне это понравилось простотой

skywriterвадя http://findevelop.blogspot.ru/2013/10/web-spring-security-100.html
мне это понравилось простотой
А что в этом хорошего (ну кроме как учебного примера изпользования фильтров)?
1) маски URL захардкожены:
private class Rule {
public static final String USER_ANY = "*";
public static final String URL_ANY = "/*";
2) файл с правами разположен в папке с классами (read-only? modify on redeploy?):
@Override
public void init(FilterConfig filterConfig) throws ServletException {
BufferedReader res = new BufferedReader(new InputStreamReader(filterConfig.getServletContext().getResourceAsStream("/WEB-INF/classes/users.txt")));
3) права заданы в файле, а не в БД;
4) не реализованы другие способы авторизации, как, н-р, LDAP или сторонний сервис;
5) не предусмотрены группы;
6) нет защиты против CSRF-аттак.
А если всё это изправлять, то чем оно будет лучше изпользования Spring Security?

По-моему, данная статья как нельзя лучше подтверждает тезис, который в автор пытается опровергнуть:
"Нельзя делать свои велосипеды! Надо использовать проверенные и отлаженные библиотеки!"
ты дурак.
это предложена идея
которую можно развить.
выложи свою критику автору и не оффтопь здесь

Petro123вадяты дурак.
он не нарушил правила, а говорил техническим языком. Ты сказал языком кухарки. Т.е. перешёл на личности.
я так понимаю, что обсирать чужой код - это спецкурс при обучении java. и нетерпммость к чужому коду это верх. пусть он и техническим языком, но он обосрал, чужой код, чужое мнение, а это просто не прилично

skywriterА что в этом хорошего (ну кроме как учебного примера изпользования фильтров)?
1) маски URL захардкожены:
private class Rule {
public static final String USER_ANY = "*";
public static final String URL_ANY = "/*";
2) файл с правами разположен в папке с классами (read-only? modify on redeploy?):
@Override
public void init(FilterConfig filterConfig) throws ServletException {
BufferedReader res = new BufferedReader(new InputStreamReader(filterConfig.getServletContext().getResourceAsStream("/WEB-INF/classes/users.txt")));
3) права заданы в файле, а не в БД;
4) не реализованы другие способы авторизации, как, н-р, LDAP или сторонний сервис;
5) не предусмотрены группы;
6) нет защиты против CSRF-аттак.
А если всё это изправлять, то чем оно будет лучше изпользования Spring Security?

По-моему, данная статья как нельзя лучше подтверждает тезис, который в автор пытается опровергнуть:
"Нельзя делать свои велосипеды! Надо использовать проверенные и отлаженные библиотеки!"
человек привел пример что можно сделать...
придираться - это не есть хороший тон.
если тебе не нравится "маски URL захардкожены" это не означает, что это не правильно.
где расположен файл- тебя не нравится - можешь , расположить там , где понравится...
права заданы там , где автор посчитал для себя приемлимым, не нравится - ни кто не заставляет, используй свой вариант
4) а автору это надо было?
5) а автору это надо было?
6) нет и защиты от других атак.
всё на уровне "мне не нравится"
я не использую Spring Security, но на основании этого решения , сделал и защиту, и права из базы, и прочие вещи.
и без Spring Security....