Вход в веб-сайт в Java + Google App Engine

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

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

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

Довольно простой материал.

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

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

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

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

Итак, вопрос становится, что люди делают по этому поводу? Twitter поддерживает как HTTP, так и HTTPS, но по умолчанию используется HTTP для его REST API. Значит ли это, что люди пароли летают без защиты, готовы к перехвату с помощью man-on-the-middle hacks?

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

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

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

Cheers, Шейн

Ответ 1

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

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

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

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

Ответ 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 Accounts.

Возможно, я что-то упустил, но документы Google просто просматривают эту зияющую дыру: (

Ответ 3

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

Ответ 4

Я пытаюсь сделать то же самое с помощью сервлета элемент ограничения безопасности. В моем приложении основной/дайджест auth под https отлично.

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

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

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

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

spring поддерживается поддержка