2015-04-22 2 views
1

У меня есть следующий прецедент, для которого мне нужны некоторые указатели/подсказки/подходы для решения.Общее управление сеансом аутентификации Domino

Мне нужно сделать экран входа в систему для Android-приложения, после которого будут другие экраны, которые будут делать исходящие вызовы REST с сервером, размещенным в Domino.

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

Теперь проблема часть

  1. Я не хочу сервер, чтобы изменить свой код для андроида как сервер выполняет запросы либо для андроид приложение или веб-приложений с теми же данными. Как я могу достичь пользовательской области (то есть, я могу знать, что последующие операции выполняются тем же пользователем, который только что вошел в систему через приложение Android) через базовую аутентификацию. Я подозреваю, что Domino не позволяет вам получить доступ к идентификатору сеанса или идентификатору подлинности DOM, который браузер сам по себе проходит в случае веб-приложения. Как я могу достичь этой функциональности из приложения Android?
  2. Если я использую базовую аутентификацию и отправлю данные, тогда я заметил, что если я установил переменную с ограниченным сеансом во время первого вызова PUT, тогда я не получу это значение, пока я пытаюсь извлечь его в следующем вызове GET из моего приложения для Android , Я считаю, что сеанс больше не существует между этими двумя вызовами?
  3. В случае базовой аутентификации сервер должен сделать что-то дополнительное в последующих вызовах после успешного входа? например: для получения списка студентов в конкретном университете с использованием REST api, но для проверки того, имеет ли пользователь право на такой сервер операций, он должен знать об этих правах доступа пользователя, которые в целом хранятся в виде информации о сеансе в процедуре аутентификации на основе сеанса.

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

Благодаря

+0

Это очень широкий набор вопросов - на границе слишком широкой для stackoverflow. У меня нет всех ответов, но я думаю, что вы можете решить проблему №1 с помощью правила переопределения сеанса аутентификации. Для получения дополнительной информации см. Http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Authenticating_Domino_REST_Service_Requests. Что касается проблемы №2, пожалуйста, уточните этот вопрос. Запросы REST обычно неактивны, поэтому я не знаю, что вы подразумеваете под «некоторой переменной области сеанса». Какая сессия? –

ответ

2

Re: это

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

Domino просто использует файлы cookie для передачи информации о сеансе взад и вперед клиенту. В зависимости от того, какой тип сеансовой аутентификации вы настроили на сервере, это либо DomAuthSessId, либо LtpaToken. См. here для получения дополнительной информации.

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

+0

Тем не менее, я согласен с тем, что сказал @Dave Delay в своем комментарии. Если вы используете REST API (например, Domino Data Service), он должен быть неактивен, и для этого выполняется обычная аутентификация. –

+0

Спасибо за ваш ответ. Извините, если мой вопрос ушел с крючка, но я смог решить это, используя то, что вы сказали. Я использую DomAuthSessId для добавления заголовка Http с каждым последующим вызовом, и он отлично работает. Тем не менее, я использую в первый раз базовую аутентификацию из приложения Android. Считаете ли вы, что я могу использовать другой механизм проверки подлинности, теперь, поскольку мне не нужно каждый раз отправлять пароль пользователя на сервер, поскольку он просто проверяет DomAuthSessId в заголовке http для последующих вызовов! – k2ibegin

+0

Я хочу, чтобы вы уже использовали аутентификацию сеанса, иначе cookie DomAuthSessionId не существовал. Поэтому нет причин продолжать отправлять идентификатор пользователя и пароль с каждым запросом. –

Смежные вопросы