Создаю сайт с возможностью регистрации.
При входе/выходе очень не желательно, чтобы пользователя всегда скидывало на главную страницу, поэтому нужно знать имя(название файла в файловой системе) текущей страницы: в принципе можно прописать имя каждой страницы в её начале, но лучше будет определять его динамически.
Как?

Как известно, JSP преобразуется в сервлет, который потом компилируется в файл класса.
В Tomcat имя класса формируется так: берется имя JSP документа и к имени добавляется постфикс "_jsp". Например, если файл был test.jsp, то класс - test_jsp, a файл класса, соответственно test_jsp.class. 
Думаю что в других серверах действуют подобные соглашения.
Ну а имя класса элементарно узнать через reflection.

А можно код. Просто я изучаю непосредственно JSP, т.к. в остальных отношениях Java мне не очень понравился.

Попробовал сделать в файле about_user.jsp такое: <%= this %>
Выводит: org.apache.jsp.about_005fuser_jsp@6a48e4
Перед user почему-то оказалось 005f и в общем какой-то ненадёжный, мне кажется, метод.

Есть идея объявить статическую переменную, которой будет даваться значение ещё при компиляции и это будет имя jsp файла:
<%! private static String filename = имя_файла; %>, но как определить тогда имя фалйа?

А если так - this.getClass() .getSimpleName() ?

Вообще-то смысла пытаться узнать  текущий jsp нет, так как могут быть еще GET параметры, уж лучше узнавать текущий URL. 

Более оптимальный вариант - возвращать на referrer (адрес страницы, с которой был осуществлен переход на сервлет логина).


п.с. наличие любой логики в JSP, за исключением логики отображения - довольно плохой стиль программирования.

Уже лучше, выдаёт: about_005fuser_jsp, но всё-таки 005f всё портит.

Как?

Я в регистрациях не разбираюсь, но пока у меня план такой: каждая страница состоит из 3 частей:
1) Вверх (подключается <%@ include file="common/top_bar.jsp" %>)
2) Лево (подключается <%@ include file="common/left_bar.jsp" %>)
3) Основная часть (у всех страниц своя)
Поля с запросом логина/пароля - в левой части(которая подключается), в этой же части проверка, не пришёл ли к нам логин/пароль из Cookies или через POST параметры. Если пришёл, то подключаемся к базе, делаем проверку и, если логин/пароль были присланы через параметры, то добавим их в Cookies.
Пока в файле common/left_bar.jsp строчка начала формы авторизации выглядит так: <form action="index.jsp" method="post"> и, если мы заходим с главной страницы, то всё нормально: были на главной, остались на главной, а если мы заходим с любой другой страницы, то получится нежелательный переход.
К сожалению, я пока не очень продвинут в серверном программировании и всё пишу в JSP файле, но в нём всё-таки есть 2 части: в одной мы делаем всю логику и выставляем значения boolean переменным, а в другой в зависимости от этих значений производим отображение.

Если у меня плохая схема, подскажите, как лучше.

nns2009, 

Не тратьте впустую время. Почитайте вдумчиво сериал.





Хранить логин и пароль в Cookies категорически запрещается - это дыра в безопасности вашего сайта.



создаете login servlet, который принимает данные, выполняет необходимые для авторизации действия, после чего редиректит на предыдущую страницу, адрес которой берет из referer  (что-то типа request.getHeader("Referer");  )

Почитаю.


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

А в чём смысл? Почему нельзя сделать авторизацию непосредственно на конечной странице?

nns2009, 



Рекомендую отложить изобретение велосипеда с квадратными колесами и начать читать. 




пароль, такая вещь, которая вообще нигде не должна храниться, кроме как в голове пользователя (даже в базе должен лежать хэш). А Вы его в общедоступный (для любого пользователя компьютера) куки засунуть хотите, да еще и при каждом запросе гонять туда-сюда.




На каждой странице?

Это сообщение отредактировал(а) Vasay - 13.5.2010, 22:20

Я не совсем разбираюсь в шифровке информации, но если у злоумышленника есть доступ к моей базе данных, то у них есть доступ и к коду захода, регистрации, где хранится алгоритм кодировки, а если знаешь как зашифровано, то и расшифровать можно, тогда какая разница хранятся пароли в открытом доступе или в зашифрованном? Как же обойтись без куки я вообще не представляю, ведь они для этого и созданы.


На каждой странице будет: <%@ include file="common/left_bar.jsp" %>

Я обязательно в ближайшее время начну читать, просто у меня в школе последняя неделя учёбы(9 класс), а по некоторым предметам вместо 4-ок, которые я ожидал, возможны 5-ки, придётся исправлять.

Прочитал первые 5 страниц. Ничего не понял: кто такие логгеры и т.д.
Насколько я понял всю логику нужно выносить в отдельный сервлет и только потом передавать в JSP данные для отображения, но так и не понятно:
1) Чем хуже делать в начале каждой страницы <%! include file="common/logic.jsp" %> (единственный минус - некрасивые имена страниц(example.ru/some.jsp, вместо example.ru/some/)), чем компилировать сервлет вручную.
2) Что нужно прописать в файле web.xml, чтобы на любые запросы выполнялся 1 и тот же сервлет, который уже в зависимости от запроса покажет ту или иную страницу(или, что такой страницы нет)
3) Как обойтись без куки?

Ну и парочка вопросов чисто о Java:
1) Есть ли getters, setters(аналог в ActionScript 3.0:

)

2) Можно ли перегружать операторы, как в C++

Во первых - не факт что получив доступ к базе человек имеет доступ к коду приложения. Во вторых читаем про hesh .



Те кто ведут LOG

По всем остальным вопросам - читайте тему думайте.  Разбирайтесь в коде, который выкладывается в теме. 

По языку Java тоже что-нибудь обязательно почитайте.

Смысл понятен: если человек не имеет доступа к коду, то он не узнает пароль, но если у него есть доступ к коду, то для восстановления пароля из базы данных он всего-лишь выполняет обратные действия: Предположим, что наши пароли целочисленные, пользователь вводит при регистрации пароль 12345, который помещается в таблицу в виде хеша: ((12345 * 3) - 1000) * 2 = 72070, злоумышленник же: (72070 / 2 + 1000) / 3 = 12345.
С остальными кодами будет то же самое. Можно ли что-нибудь предпринять против этого или система хеширования разрабатывалась для первого случая?


Кто это: пользователи или это специальные встроенные функции для упрощения регистрации/входа/выхода?


Чтение будет продолжено.

nns2009, 



Боюсь, все же не понятен.  Хэш - необратимое преобразование.