Выполняет ли аутентифицированный запрос REST ВСЕГДА подразумевает запрос базы данных?

Question

Я использую RESTeasy framework для разработки своего веб-сервиса. Мне удалось настроить аутентификацию BASIC, и теперь она работает правильно. Конечно, я планирую использовать SSL поверх этого.

Процесс очень прост (и, пожалуйста, read something о HTTP базовой аутентификации, если вы не знаете, о чем речь):

1. Каждый запрос перехватывается способом, который анализирует заголовок запроса.
2. Этот заголовок декодируется и извлекается имя пользователя и пароль.
3. Затем метод запрашивает базу данных, чтобы проверить соответствие имени пользователя и пароля.
4. Если они соответствуют запросам, если они этого не делают, возвращается код 401.

При таком подходе каждый запрос подразумевает запрос к базе данных из-за безгосударственного характера REST (и самого HTTP).

Мой вопрос: возможно ли запрашивать базу данных по каждому аутентифицированному запросу?

Возможные подсказки: какой-то механизм с использованием печенья?

Этот вопрос является технологически неактивным.

---

Так же, как примечание стороны:

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

спасибо.

Answer 1

Ответ закончился кэш.

В моем конкретном случае я использовал RESTeasy как структуру REST и Google App Engine в качестве сервера приложений. Нетрудно было узнать, что GAE поддерживает memcache.

Если вы используете Objectify (вам действительно нужно, это потрясающе), это еще проще. Просто комментируйте свои сущности с помощью @Cached. Эта процедура проиллюстрирована here.

Objectify поддерживает другой вид кеша в сеансе Object. Другими словами, до тех пор, пока ваш объект Objectify не будет создан, он может предоставить ваши объекты даже без использования memcache (это хорошо, потому что в GAE есть квоты для использования memcache, хотя они дешевле, чем у хранилищ данных). Я настоятельно рекомендую вам ознакомиться с полезными практиками Objectify в своей вики.

В заключительной ноте, я буду считать, используя Digest аутентификации вместо Basic. Это кажется гораздо более безопасным. Тот факт, что пароль никогда не путешествует по сети, действительно облегчает меня.

Я надеюсь, что этот вопрос был полезен кому-то и тем, кто помог мне: спасибо. :)

Answer 2

Существуют различные способы реализации «Аутентичного билета» (google и, возможно, вы найдете некоторые ссылки, отличные от OAuth), с кукисами, чтобы не каждый запрос требовал запроса базы данных. Однако обычно они включают крипто-ключ.

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

Как утверждается, добавление cookie (состояния) в конструкцию системы без гражданства - это своего рода обман.

Answer 3

Используйте что-то наподобие memcached как промежуточное звено в базе данных. Проверьте, кэшируются ли учетные данные, если они продолжаются с запросом, если они не кэшированы, вытащите их из базы данных и проверьте учетные данные. Если учетные данные соответствуют кэш-памяти для будущих запросов и продолжаются с текущей.

Имейте в виду, что доступ к memchaced должен быть таким же безопасным, как доступ к вашей базе данных, поскольку он хранит пароли, хранящиеся в нем. Это одна из причин. Многие сайты используют OAuth, особенно OAuth 2, где вы раздаете краткосрочный токен доступа и долгоживущий токен обновления, который при необходимости получит новый токен доступа.

Answer 4

Добро пожаловать в мир представительной государственной безопасности Tranfer! Вы знаете, я отправил сообщение Рою Филдингу, спрашивая, как вы могли бы создать действительно RESTful-сервис, который также был безопасным. Он еще не вернулся ко мне.

Ваши две опции - это Basic Auth (надеюсь, с использованием SSL, или в чем смысл) или OAuth. Для всех решений, с которыми я сейчас сталкиваюсь, мы используем OAuth. Хотя это усложняет тестирование, оно очень безопасно и позволяет нам создавать внешние API из наших сервисов.

Я советую использовать файлы cookie для хранения информации о сеансе. Это не только нарушает дух REST, но также открывает ваше приложение для захвата сессии. Одна вещь, которую вы можете сделать, чтобы ускорить работу, - это сохранить хороший кеш второго уровня с информацией о пользователе, чтобы ваши запросы фактически не попадали в БД для каждого входящего запроса. Это может дать Значительное ускорение скорости. Эта тактика одинаково хорошо работает как для базового auth, так и для Oauth.

Answer 5

Если вы интегрируетесь с UserService of AppEninge (и как таковые с учетными записями Google), вы можете предотвратить любые запросы. RESTlet имеет супер элегантный аутентификатор, который поставляется с каркасом:

public class GaeAuthenticator extends Authenticator { 
    /** 
    * The GAE UserService that provides facilities to check whether a user has 
    * authenticated using their Google Account 
    */ 
    private UserService userService = UserServiceFactory.getUserService(); 

    /** 
    * Constructor setting the mode to "required". 
    * 
    * @param context 
    *   The context. 
    * @see #Authenticator(Context) 
    */ 
    public GaeAuthenticator(Context context) { 
     super(context); 
    } 

    /** 
    * Constructor using the context's default enroler. 
    * 
    * @param context 
    *   The context. 
    * @param optional 
    *   The authentication mode. 
    * @see #Authenticator(Context, boolean, Enroler) 
    */ 
    public GaeAuthenticator(Context context, boolean optional) { 
     super(context, optional); 
    } 

    /** 
    * Constructor. 
    * 
    * @param context 
    *   The context. 
    * @param optional 
    *   The authentication mode. 
    * @param enroler 
    *   The enroler to invoke upon successful authentication. 
    */ 
    public GaeAuthenticator(Context context, boolean optional, Enroler enroler) { 
     super(context, optional, enroler); 
    } 

    /** 
    * Integrates with Google App Engine UserService to redirect 
    * non-authenticated users to the GAE login URL. Upon successful login, 
    * creates a Restlet User object based values in GAE user object. The GAE 
    * "nickname" property gets mapped to the Restlet "firstName" property. 
    * 
    * @param request 
    *   The request sent. 
    * @param response 
    *   The response to update. 
    * @return True if the authentication succeeded. 
    */ 
    @Override 
    protected boolean authenticate(Request request, Response response) { 
     ClientInfo info = request.getClientInfo(); 
     if (info.isAuthenticated()) { 
      // The request is already authenticated. 
      return true; 
     } else if (userService.isUserLoggedIn()) { 
      // The user is logged in, create restlet user. 
      com.google.appengine.api.users.User gaeUser = userService 
        .getCurrentUser(); 
      User restletUser = new User(gaeUser.getUserId()); 
      restletUser.setEmail(gaeUser.getEmail()); 
      restletUser.setFirstName(gaeUser.getNickname()); 
      info.setUser(restletUser); 
      info.setAuthenticated(true); 
      return true; 
     } else { 
      // The GAE user service says user not logged in, let's redirect him 
      // to the login page. 
      String loginUrl = userService.createLoginURL(request 
        .getOriginalRef().toString()); 
      response.redirectTemporary(loginUrl); 
      return false; 
     } 
    } 
}