Автоматическая аутентификация по электронной почте

Question

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

Для получения имени пользователя я использую @Formulas. Следовательно, я могу использовать свой метод аутентификации в любой ссылке или точке доступа или кнопке в Notes Client. Но я сталкиваюсь с проблемой отправки этого метода через ссылки электронной почты напоминания.

Когда я создаю URL-адрес через бэкэнд-агент, этот URL-адрес/точка доступа должен иметь мой код с @formula. Простыми словами, я хочу передать @Dblookup внутри URL/hotspot через мою ссылку по электронной почте. Как выполнить эту задачу?

Или есть ли альтернатива для получения имени пользователя, если кто-либо щелкнет ссылку в своем письме?

Клиент только Notes должен использоваться.

---

Edit # 1: Добавление сценария для лучшего объяснения:

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

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

Answer 1

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

И поскольку это для получателей клиентов Notes, другая техника, исследовать - это использование сообщения в форме магазина в документе вместо обычного сообщения электронной почты. Таким образом вам просто нужно иметь кнопку, содержащую @DbLookup, в форме, которую вы отправляете в сообщении.

Answer 2

Я согласен с leyer. ACL (список контроля доступа) является основным инструментом для использования функций. Например, пользователь может иметь доступ к db. Затем вы можете определить, кто может создавать базы данных, создавать электронные письма. Лучше всего использовать ACL, чтобы вы могли также использовать роли и другие инструменты. Основной LotusScript может получить доступ к ACL в открытых событиях или выполнить тест в кнопках.

Answer 3

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

От admin help:

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

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

При использовании окна на основе серверов, можно даже осуществить SPNEGO, автоматически подписывать пользователей при помощи дер учетной записи Windows, поэтому устранение Логин подсказки полностью.

С Domino 9 у вас также есть возможность использовать Security Assertion Markup Language (SAML) to configure federated-identity authentication.

В вашем случае я бы начал с аутентификации на основе имени и пароля для решения проблемы множественного входа.