Альтернатива для передачи идентификатора пользователя и пароля через апплет Java?

Question

Апплет поможет пользователю создать объекты класса java, которые будут отправлены на сервер PHP, который будет хранить объект в виде большого двоичного объекта в базе данных MySQL. Обратное тоже должно сработать - чтение данных обратно.

Пользователь должен будет войти на сервер PHP, чтобы просмотреть этот апплет. Но в то же время я не хочу оставлять апплет открытым, чтобы иметь доступ к базе данных (через PHP) без пароля.

Соединение будет таким:
Java-апплет - отправка потока URL -> PHP Script - Authenticate - при действительном подключении к БД -> MySQL DB

Я хочу, чтобы этот процесс аутентифицировал пользователя, но в то же время я не хочу, чтобы пользователю приходилось снова входить в систему после входа на веб-сайт, и в то же время я не хочу, чтобы апплет сохранял любая безопасная информация, потому что это не безопасно.

Есть ли способ здесь? Или мне придется искать альтернативу? (Если да, то какая альтернатива?)

Answer 1

При вызове апплета должен войти тот же сеанс HTTP, который уже был создан сервером, когда пользователь зашел на сайт.

Сеанс создается сервером, и сервер отправляет идентификатор сеанса в виде специального файла cookie. В случае серверов на базе Java это обычно jsessionid. Сервер отправляет куки, используя HTTP-заголовок ответа с именем Set-Cookies. Клиент должен отправить все куки обратно, используя заголовок Cookies.

Итак, ваш апплет должен иметь доступ к файлам cookie, хранящимся в браузере, и отправлять их. Чтобы получить доступ к куки-файлам браузера, вы должны использовать LiveConnect API, который позволяет маплету вызывать javascript со страницы, содержащей его.

Answer 2

Ваш апплет должен иметь возможность считывать куки со страницы, на которой он отображается.Таким образом, предполагая, что пользователь прошел аутентификацию на веб-странице, вы можете получить от него идентификатор сеанса (или любой другой) со страницы и использовать его для «аутентификации» на вашем сервере.Однако имейте в виду, что, если вы не используете зашифрованный сеанс (https), эти файлы cookie могут быть прочитаны при передаче третьими лицами.Кроме того, вы должны знать, что любые сторонние скрипты на вашей странице также смогут читать эти куки.

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