Аутентификация для Cookie или ключ RESTful? - PullRequest
2 голосов
/ 07 января 2012

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

Я очень заинтересован в веб-сервисах RESTful: на веб-сервере без состояния код гораздо удобнее для чтения, сопровождения и изменения, чтобы назвать несколько преимуществ. Будучи студентом колледжа, работающим независимо над этой реализацией, эти вещи не являются для меня чрезвычайно важными, но я считаю, что управляемая реализация REST была бы идеальной с точки зрения кодирования.

Поскольку моему приложению требуются учетные записи пользователей, которые поддерживают свои собственные контексты, пользователи должны будут проходить проверку подлинности при отправке запросов веб-серверу. Если бы я реализовал это приложение полностью в режиме RESTful, я бы не поддерживал сеансы любого рода, а вместо этого требовал бы, чтобы приложение Android (на стороне клиента) передавало учетные данные текущего пользователя (вероятно, единственный уникальный ключ, возвращаемый приложению Android). с веб-сервера при первом входе в систему) при каждом запросе. Это был бы правильный подход, но я беспокоюсь о вычислительных затратах, которые могут возникнуть на стороне сервера.

И вот почему:

  • Поиск пользователя по длинной строке в каждом запросе для того, чтобы воздействовать на этого пользователя, будет медленнее, чем целочисленный идентификатор пользователя для связанной строки таблицы в сеансе CookieStore.

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

Когда мне в конечном итоге требуется хостинг для производственного сервера, я действительно не могу позволить себе платить за зверя, просто чтобы я мог носить значок REST.

Предполагая, что обычный пользователь делает 10-30 запросов в день, а количество пользователей зависит от популярности приложения (что я не могу предсказать, но ради этого вопроса, предположим, что оно среднее) Реально ли реализовать аутентификацию RESTful в моем конкретном случае? Другими словами, могут ли вычислительные накладные расходы существенно увеличить требования к оборудованию для сервера?

Спасибо

1 Ответ

0 голосов
/ 20 января 2012

В своих проектах я обычно использую другой подход.

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

В основном я что-то делаювот так:

key = User.id.to_s + SHA1::Digest.hexdigest("#{SECRET_KEY}#{User.id}#{User.name}#{User.created_at.to_i}")

Поскольку длина хэша SHA1 известна, вы можете извлечь id и токен из строки без использования какого-либо специального разделителя.Таким образом, вы можете получить два преимущества:

  1. Нет необходимости хранить ключ в БД, так как он может быть вычислен по требованию.
  2. Ключ, возвращаемый пользователю, короткий (сетевойвыгодно) и легко отправить (потому что в ASCII нет необходимости в Base64 или аналогичном)

Надеюсь, это поможет!

...