ServiceStack: Сохранение настраиваемого объекта пользователя без AuthUser

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

Проблема, с которой я сталкиваюсь, заключается в том, что если я сохраняю встроенный объект UserAuth как есть, CB использует поле Id в качестве идентификатора документа. Это проблема, потому что я считаю, что идентификатор должен быть специфичным для типа объекта, в противном случае потребуется отдельная «корзина» для предотвращения конфликта идентификаторов между разными объектами. Я действительно не хочу иметь много ведер, если мне не нужно.

Я бы предпочел, чтобы идентификатор документа был установлен в соответствии с типом объекта плюс конкретный идентификатор объекта.

например, с использованием идентификатора «UserAuth_1234» или имени пользователя «UserAuth_MikeGoldsmith»

Верно ли мое предположение о попытке повторно использовать ведро для различных объектов приложения, или я должен думать о ведре для каждого типа объекта / пространства имен?

Любые указания будут приветствоваться как от энтузиастов Couchbase, так и от ServiceStack.

Спасибо

Дополнительная информация

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

Я нашел это сообщение , где Mythz предлагает пример BootStrapApi. расширяет AuthUser настраиваемыми свойствами. Однако мне кажется, что AuthUser сохраняется дважды, сначала как AuthUser, а затем как объект User (оба раза с использованием OrmLiteAuthRepository). Я прав?

По сути, я хочу использовать функцию аутентификации SS, но контролировать объект POCO, который будет сохранен в Couchbase. Может ли кто-нибудь дать какое-то направление, если это возможно, и если да, то что мне нужно реализовать / подключиться?

Я пробовал реализовать версию IUserAuthRepository Couchbase, однако она использует конкретный тип UseAuth, поэтому я не могу использовать свой собственный объект.

Я также попытался подключиться к OnAuthenticated методу AuthUserSession, но на этом этапе UserAuth POCO будет сохраняться с использованием регистра IUserAuthRepository.

Я счастлив использовать CredentialsAuthProvider, так как мне просто нужна аутентификация по имени пользователя и паролю. Больше можно будет добавить позже.

Спасибо еще раз!


person Mike    schedule 12.02.2013    source источник


Ответы (2)


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

Имейте в виду, что в Couchbase в документе нет поля, которое считается полем «id» или «key». Ключ, используемый для хранения документа, доступен в метаданных, но не является частью самого документа JSON. Поэтому, если вы можете воспользоваться преимуществами представлений, вы также можете сохранить документ с атрибутом типа, а затем запросить по некоторому свойству, не являющемуся идентификатором. Другими словами, ключ в значении ключа не обязательно должен быть тем способом, которым вы получаете документ аутентификации пользователя.

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

person John Zablocki    schedule 12.02.2013
comment
Идея ведра на БД, объекта на дизайн и представления на запрос пока кажется правильной. - person Mike; 13.02.2013
comment
(Случайно нажал Enter слишком рано и не могу отредактировать свой первый пост, так что вот оставшаяся часть моего комментария) Я создал свои модели, чтобы иметь свойства id и type; ключ, который я использую для сохранения документа, представляет собой комбинацию этих двух, то есть {type} _ {id}. Как вы предлагаете, я думаю, это стандартная схема, очень похожая на то, как работает пивной тест CB. Проблема, с которой я столкнулся, больше связана с ServiceStack. Я хочу использовать настраиваемый пользовательский объект и сохранять CB без сохранения объекта SS AuthUser. Благодарим за разъяснения по передовой практике таксономии сегментов / документов. - person Mike; 13.02.2013

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

Мне удалось переопределить метод TryAuthenticate и использовать свой собственный UserRepository, который поддерживает Couchbase.

person Mike    schedule 13.02.2013
comment
Привет, Майк, ты можешь отметить свой ответ как принятый, чтобы помочь другим, кто столкнется с твоим вопросом при обращении за помощью. - person DanB; 14.02.2013
comment
Привет, Дэн, я пытался, но ТАК мешает мне ответить на мой вопрос еще пару часов. Я сделаю это, когда истечет время, спасибо. - person Mike; 14.02.2013