GWT: аутентификация для некоторой части приложения с использованием страницы входа в GWT - PullRequest
4 голосов
/ 28 июня 2011

Мое приложение имеет некоторые функции, которые доступны всем пользователям, а также некоторые другие функции, доступ к которым должен быть ограничен только аутентифицированным пользователям.Все эти ограниченные функции существуют в некотором наборе Мест GWT, поэтому все Места, доступные в приложении, можно разделить на две группы: «доступные для всех» и «ограниченные».На мой взгляд, места с ограниченным доступом могут реализовывать некоторый интерфейс (скажем, это будет RestrictedAccess), и если пользователь перейдет к одному из них, и он еще не прошел проверку подлинности, он будет перенаправлен на экран входа в систему -это скорее ОО-подход, чем применение фильтров на основе URL.

То, чего я пытаюсь добиться, это:

  1. Информация о том, прошел ли пользователь аутентификацию или нет, должна храниться на сервере (это не то, что может быть сохранено в cookie-файле...)
  2. Страница входа - это стандартное место GWT + просмотр + активность (!)
  3. Проверка имени пользователя и пароля выполняется на стороне сервера.

До сих пор я представил интерфейс RestrictedAccess, который реализован в некоторых местах.Моя реализация FilteredActivityMapper.Filter, которая передается в маппер активности приложения-оболочки FilteredActivityMapper, имеет следующую логику:

Place filter(Place place) {
    if (place instanceof RestrictedAccess && !userHasBeenAuthenticated()) {
      return new LoginPlace();
    }

    // return the original place - user has been already authenticated or
    // place is accesible for all users
    return place;
}


private boolean userHasBeenAuthenticated() {
    // remote call - how to do ???
}

Проблема связана с методом userHasBeenAuthenticated() (пользователь не должен быть перенаправлен на LoginPlace, если онуже был аутентифицирован).Если я хочу сохранить эту информацию на стороне сервера, я должен выполнить GWT RPC / вызов фабрики запросов здесь, но оба они асинхронные, поэтому я не могу работать с его результатом в методе filter.

Я знаю, что могу использовать фильтры web.xml или какую-то внешнюю среду (например, Spring Security), но ни один из этих подходов не позволяет мне иметь страницу входа в качестве стандартной формы на основе GWT или указывать более OO-способом, что доступ к некоторымместо должно быть ограничено.

Заранее благодарен за любые подсказки

РЕДАКТИРОВАТЬ : я начал задаваться вопросом, должна ли происходить фильтрация мест (ограниченная / не ограниченная) нана стороне клиента вообще.Если, как было предложено, существует возможность взломать код, указывающий, прошел ли пользователь проверку подлинности или нет, существует также возможность взломать места фильтрации кода, чтобы можно было получить доступ к закрытым местам без входа в систему.

Ответы [ 2 ]

3 голосов
/ 28 июня 2011

Piotrek,

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

Решение, которое я реализовал, состоит в том, чтобы просто возвращать SC_UNAUTHORIZED, если неаутентифицированный пользователь пытается получить доступ к какой-либо удаленной службе.Я переписал функцию RequestFactory onResponseReceived, которая перенаправляет на страницу входа в систему, если ответ SC_UNAUTHORIZED.Идея взята из: http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/client/GaeAuthRequestTransport.java

Это работает для нашей ситуации, когда все действия и места ориентированы на данные - каждое изменение места получает данные с сервера.Если пользователь не аутентифицирован, он просто не получает данные и перенаправляется на страницу входа в систему.

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

2 голосов
/ 28 июня 2011

У меня есть похожее приложение с теми же требованиями.Пока я не дошел до реализации, но я думал в том же духе.

То, что я планировал сделать, - это сохранить клиентскую часть состояния аутентификации в классе AuthenticationManager.Когда приложение запускалось, я собирался запросить информацию о входе в систему с сервера (я думал о запуске на движке приложения, чтобы получить состояние аутентификации, а также URL-адреса входа / выхода с открытым идентификатором) и сохранить его в AuthenticationManager.Acegi / Spring Security работает аналогичным образом, поэтому эта информация доступна на стороне сервера, если вы тоже ее используете.

Когда пользователь входит в систему / выходит из системы, он будет перенаправлен сервером и будет получено новое состояние.Это должно поддерживать состояние аутентификации клиента в соответствии с сервером.Каждый запрос RPC на сервере также должен быть проверен на аутентификацию.Я использовал библиотеку gwt-dispacth, и в ней также есть некоторая элементарная проверка подлинности и межсайтовая защита сценариев (хотя я думаю, что в последних версиях GWT есть это для универсального RPC).

Одна проблема - это тайм-ауты сеансов.Снова библиотека gwt-dispath имеет некоторый код, который обнаруживает это и возвращает клиенту исключения истекшего сеанса, которые могут быть перехвачены и обновлен диспетчер аутентификации.

Надеюсь, что это имеет смысл.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...