Вход на сайт в Java + Google App Engine

Question

Я новичок в веб-программировании, пришёл из среды разработки видеоигр (c ++) и действительно начинаю ощущать информационную перегрузку. Существует так много конкурирующих библиотек, которые выбирают то, что им не нравится в какой-то другой библиотеке, и создают совершенно новый способ сделать то же самое! Я уверен, что для этого есть веские причины, и я не хочу жаловаться, поэтому я объясню свою проблему.

Чтобы облегчить свое путешествие, я решил начать изучать Google App Engine + GWT + Java. Мне это нравится, потому что это распределенная серверная архитектура, и я выбрал Java из-за своего опыта работы с C ++.

Для начала я написал небольшое приложение, похожее на Twitter, потому что оно тестирует различные аспекты веб-разработки, а именно: REST, анализ / создание JSON, AJAX-связи и генерацию HTML. У меня не заняло много времени создание небольшого сайта, который позволял бы пользователю вводить свое имя и пароль на странице в браузере, отправлять данные в мое приложение, я входил от их имени, брал их список друзей и отправлял сообщения он возвращается к клиенту как JSON, где я его анализирую и отображаю.

Довольно простые вещи.

Итак, следующим шагом было то, что мне не понравилось посылать пароль, который пользователь ввел по сети, в виде простого текста (очевидно). Это заставило меня задуматься о всей сантехнике, которая мне понадобится:

1. Аутентификация пользователей по моей собственной базе данных, а не по Google. (Логин / Забыли пароль / Выйти)
2. Вход / выход (отслеживание) сеанса (вход / выход из системы).
3. Хранить пользовательские данные в базе данных моего приложения Google.

Все довольно стандартные вещи, которые были вокруг навсегда. Ну, я начал искать библиотеку аутентификации Java, и там были такие большие монолитные библиотеки с огромными кривыми обучения, а некоторые из них уже устарели или больше не в фаворитах ... Я снова и снова чувствую себя начинающим программистом! Я просто хочу иметь страницу входа! :)

Итак, я начал читать о том, как работает аутентификация, и есть огромное количество, которое нужно принять. Очевидно, что люди довольно часто (небезопасно) бросают свои собственные. Я бы предпочел принять решение, которое существует и является надежным.

Таким образом, возникает вопрос, что люди делают с этим? Twitter поддерживает как HTTP, так и HTTPS, но по умолчанию использует HTTP для своего REST API. Означает ли это, что пароли людей разлетаются без защиты, готовые к перехвату взломами типа «человек посередине»?

Я также посмотрел на OAuth, который выглядит превосходно, но в нем нет аргумента просто для старого доброго «я не хочу знать или беспокоиться о том, что такое OpenID». Нетехнические люди, которым я показывал OpenID, похожи на «что? Я просто хочу ввести свое имя пользователя / пароль».

Как примечание: кому-нибудь повезло с Spring.Security в Google App Engine?

Во всяком случае, я ругаю. Я просто хочу знать, что делают люди (не в Python, Rails и т. Д., А в старой доброй Java). Я хотел бы иметь страницу входа в систему, как Digg, даже с возможностью один день для OpenID:)

Ура, Шейн

Answer 1

Я не могу говорить с Spring Security вместе с Google App Engine, но могу сказать несколько вещей об этом, которые могут оказаться полезными.

Во-первых, его очень просто настроить, и у него есть хорошие учебные пособия по его запуску и запуску. Лично я использовал руководство pet-clinic в качестве руководства о том, как применить весеннюю защиту в моем проекте в первый раз. Я смог настроить его в течение часа или двух, и у меня была базовая защита с использованием моей базы данных на нескольких разных страницах. Конечно, ваш пробег может быть разным, но в худшем случае у вас есть полноценное учебное пособие, которое вы можете нажать и подтолкнуть, чтобы увидеть, как оно реагирует.

Во-вторых, библиотека очень настраиваема. Если вы будете искать в руководстве , вы получите хорошее представление о том, что вы можете сделать, и у меня не возникло проблем при переработке областей, которые мне нужно было изменить для моего проекта. Я уверен, что вы сможете работать вместе с Spring Security и Google App Engine. В целом я был рад предвидению источника Spring и возможности взаимодействовать с другими библиотеками.

Наконец, Spring Security поддерживает OpenID, если вы решили, что хотите добавить слой. Я еще не играл с этой частью, но из учебника она также выглядит довольно интуитивно понятной. Здесь хорошо то, что вы можете добавить это после того, как выяснится, что вы все-таки должны были поддерживать OpenID.

Желаю вам удачи!

Answer 2

Я просто наткнулся на ваш пост. Вы, казалось (в прошедшем времени, так как прошло много времени), были озадачены использованием HTTP / HTTPS и аутентификацией. Если вы используете HTTP, ваш пароль не будет передан в виде обычного текста. Как правило, информация для входа в систему размещается через HTTPS. К этому времени уже установлен сеанс, который отслеживается с помощью большого случайно сгенерированного идентификатора в файле cookie. Пользователь аутентифицируется на сервере, и его идентификатор сохраняется в сеансе (сохраняется на сервере), чтобы отметить, что он вошел в систему.

С этого момента пользователь отслеживается через сеанс. Да, вполне возможно, что посредник может похитить печенье и принять вашу личность. Это касается 100% сайтов, работающих по протоколу HTTP, но, очевидно, это не проблема, иначе вы бы услышали об этом больше. Для HTTPS cookie сеанса может быть помечен как безопасный, что означает, что он будет когда-либо отправляться только через HTTPS из браузера. В прошлом я обнаружил, что браузеры ведут себя по-разному, иногда разделяя одно и то же значение для безопасного и незащищенного cookie с тем же именем (что является глупой идеей). Лучше всего использовать безопасный файл cookie с отдельным именем, чтобы убедиться, что пользователь вошел в систему для безопасных функций на вашем веб-сайте.

Я согласен с вами, что структура JAAS просто ужасна. Должно быть, это было написано группой сумасшедших безумцев.

Что касается использования Google App Engine - они позаботятся обо всей аутентификации за вас. Похоже, у вас нет выбора, кроме как использовать учетные записи Google, что является позором. Также жаль, что они настаивают на том, чтобы вы перенаправляли на их страницу входа в систему, потому что это нарушает работу приложения GWT. В настоящее время я пытаюсь управлять своими собственными учетными записями, потому что я не хочу, чтобы Google владел ими, и я не хочу, чтобы этот отдельный сайт был на моем сайте.

Тем не менее, кажется, что невозможно отследить пользователя без сеанса (сеансы могут поддерживаться в GAE, но настоятельно не рекомендуется содействовать масштабируемости в GAE). Без сеанса мне буквально нужно отправить пароль и аутентифицировать пользователя при каждом запросе RPC. Google применяет некоторые приемы, чтобы метод getUserPrincipal () работал на своих кластерах серверов - и, похоже, вы получите эту магию, только если вы используете учетные записи Google.

Может быть, я что-то упустил, но документы Google просто скользят по этой зияющей дыре: (

Answer 3

Привет, если вы хотите работать с Java, вы можете захотеть заглянуть в WICKET ... это довольно аккуратный Java-фреймворк, который предлагает отличные возможности. он ориентирован на компоненты и через примеры довольно прост для понимания (см. пример входа в систему на странице расширенного примера ... Я запустил его довольно быстро). он также работает с другими js-фреймворками, но также предлагает свою собственную ajax-реализацию. у него также есть отличный список рассылки!

Answer 4

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

На следующий день я также попытаюсь реализовать другое приложение, используя restlet и / или JAX-RS. Обе платформы обеспечивают защитные хуки.

Вход / выход (отслеживание) сеанса (вход / выход из системы).

это можно легко реализовать с помощью фильтра сервлетов (опять же, полностью поддерживается GAE)

Как примечание: кому-нибудь повезло с Spring.Security в Google App Engine?

поддерживается пружинная защита