Вэб авторизация клиентов

[igorgrim]

Есть база данных клиентов с некоторой информацией для каждого клиента.

Требуется предоставить каждому клиенту через Вэб доступ только к этой базе и только
к его информации.

В адресную книгу заводить всех клиентов не хочется ибо их в сотни раз больше чем сотрудников.
Заводить отдельную адресную книгу - нарушение целостности. Клиента прийдется регистрировать
и в базе и в этой адресной книге.


Внимание, вопрос.

Какие виды, возможно поля, минимально необходимо добавить в базу клиентов, чтоб именно эту базу зарегистрировать в качестве дополнительной адресной книги и через нее
работала авторизация к ней через Вэб.
Есть ли где дока на эту тему?

Кастрацией адресной книги добился что она продолжает работать в требуемом режиме если оставить только 2 вида ($Users)
и ($ServerAccess)
Но если аналогичные виды создать в чистой базе, где в поля прописать константы - не работает.
Видимо, есть еще какие-то требования к полям документов.

Также не занаю как создать зашифрованный HttpPassword.

Функция @Password, которая прописана в дизайне names.nsf
работает в новой базе не так, как в names.nsf
В чем причина? Где еще код, который изменяет значение HttpPassword при закрытии документа Person?

И последний вопрос:
Может есть более простой путь решения исходной задачи?

Большое спасибо всем откликнувшимся.

 

[Akupaka]

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

по поводу авторизации через веб не пробовал, но базу под АК в ДА делал.
мне хватило двух представлений: ($Users) и ($PeopleGroupsFlat)
как мне помнится ($Users) используется системой для поиска имен, а ($PeopleGroupsFlat) отображается в диалоге выбора имен, напр, из почтовой базы по ссылке Кому.
в обоих представлениях у меня отображались документы по форме с данными о пользователе:
FirstName - имя
LastName - фамилия
MiddleInitial - буква отчества
FullName - полное имя (= FirstName + " " + LastName )
ShortName - краткое имя (= @Left(FirstName; 1) + LastName )
AltFullName - альтернативное имя ( = FullName )
MailAddress - e-mail пользователя
InternetAddress - дублировало поле MailAddress
Type = "Person" - обязательно, иначе не срабатывает подстановка имени при вводе, в почте, в поле кому

дизайн представления я переделал немного из стандартного шаблона PAB, оставил только нужные вычисления, т.к. там использовалось больше типов документов (группы, и т.п.).
при этих данных, база удачно отрабатывала в качестве АК в ДА, если я ничего не забыл.

по-идее, для аутентификации используется инфа из поля FullName, которое может хранить несколько значений.

Также не занаю как создать зашифрованный HttpPassword. Функция @Password, которая прописана в дизайне names.nsf работает в новой базе не так, как в names.nsf

не понял, что значит "работает не так"? вроде ничего кроме формулы трансляции на поле HTTPPassword (= @Password(HTTPPassword) ) не устанавливает его значения. ты тип поля не в пароль поставил, случайно? должно быть текстовое.

обрати внимание на виды, поищи инфу, я уже не в силах
"($LDAPCN)", "($NamesFieldLookup)", "($People)", "($PeopleGroupsByLang)", "($PeopleGroupsCorpHier)", "($PeopleGroupsFlat)", "($PeopleGroupsHier)"

обрати внимание, что при смене пароля он не моментально обретает силу, а спустя 10-15 мин. говорят, что помогает задача updall.

Может есть более простой путь решения исходной задачи?

конечно, но обычно мы их находим после того как проходим сложный хз, в общем )))

 

[ToxaRat]

лучше вообще не регистрируй в лотусе, использую свою регистрацию
каждому юзеру выдай в момент входа в базу UNID
и сделай авторизацию типа

Ссылка скрыта от гостей

а UNID будет вести на временно созданный документ который и будет держать сессию
естественно во всех ссылках для каждого клиента нужно будет динамически дописывать UNID
зато свой вид аутентификации и АК не трогается

 

[Akupaka]

ToxaRat
прально, на что нам аутентификация, авторизация и тому подобная чушь!
а АК и АД вообще никому не нужная приблуда на домино!

 

[NetWood]

Имхо лотус и силен встроенными механизмами контроля доступа. Зачем кастомизируете и изобретаете велосипед?
Просто не разобрались по сути. Тоха тоже в сторону уводит. Ломается это и вообще не очень вариантик слабый.

Идете на openntf. Качаете dombulletin. Изучаете агенты регистрации в АК и прочее. Или тут я выкладывал русифицированный, но сути не меняет. Там есть полный механизм с регистрацией через веб. По сути ДОЛЖНА быть доп адресная книга + ваша база. Username базы = Usermame AK. По ним все и контролируется. Пишете разового агента который пробежит по вашей базе и сделает доки в доп адресной книге по которым будет авторизация. Каждому доку в базе назначаете поле AutorisedReaders (читатель или автор - это как решили) в которую пишете админа, или роль какую нить админскую, и собственно юзера. И будет вам счастье.

Если уж совсем будет туго - стучитесь в личку. Дам ссылу на реально работающий проект где все это работает + дописки всякие типа авторег через e-mail. Исходниками не смогу ибо коммерческое, а так советом и пинками...
Да. представления в АК не трогайте. Что мешают? Там в авторизации их используется не два и не три.
А чтоб сразу вступилов силу а не через 15 мин
'Refreshing NAB views for immediate login
Set dbreg = s.GetDatabase("",profile.GetItemValue("NABFile")(0))
Set dbreggroup = s.GetDatabase("",profile.GetItemValue("NABGroupFile")(0))
Set viewreg=dbreg.GetView("($Users)")
Call viewreg.Refresh()
Set view = dbreg.GetView("($LDAPCN)")
Call view.Refresh()
Set view = dbreg.GetView("($ServerAccess)")
Call view.Refresh()

 

[Akupaka]

Идете на openntf. Качаете dombulletin

хороший пример, кстати. но он же сам не является АК, на сколько помню, т.е. саму базу булетина нельзя ведь регистрировать в ДА? но почерпнуть всегда есть что

 

[ToxaRat]

Akupaka
NetWood
Человек изначально поставил задачу у него много пользователей, каждому нужно показывать только своё
я делал свою авторизацию без средств лотуса - очень удобно если нужно свой инет-магазин сделать и содержать

Плюсов море:
1) Не нужно ждать регистрации и кеширования лотуса
2) Не засырается АК сервера
3) Всё контролируемо и можно показывать сколько юзверей онлайн
4) на основе этих самых "временных доков - unid" при необходимости можно банить по ИП, хосту и прочему, чего АК вам не даст
5) любые логины, куки и все фичи форумов/чатов и т.д.

Из минусов:
- нужно делать грамотно и не спеша

я не ухожу в сторону
В адресную книгу заводить всех клиентов не хочется ибо их в сотни раз больше чем сотрудников
Это условие и решение под него есть, зачем юзать под это АК?

 

[NetWood]

ведь регистрировать в ДА?

Мухи отдельно - котлеты отдельно. База сама по себе, а аутентификация цепляется через доп AK. В базе храним username, адреса, всякую мишуру. В АК храним username, пароль ну и майлы. Можно поля допилить похожие как в базе, но это по желанию. Тут аффтар спрашивал про шифрование пароля. Так он и так шифруется. В чем вопрос то? А чтобы голый не передавался в браузере - для этого люди иногда пользуют https
В базе профайл. Из него извлекаем:
Set dbreg = s.GetDatabase("",profile.GetItemValue("NABFile")(0))
Set dbreggroup = s.GetDatabase("",profile.GetItemValue("NABGroupFile")(0))
в нем настройки где AK лежит и что с ней делать.

Иногда возникают проблемы у народа при подключении доп АК - не работает. из-за этого не хотят все запихивать в основной names.
Так читаем мануалы и один важный штрих. Сам наступал не раз. Имена доменов в домино и в АК должны быть РАЗНЫЕ!!!

А Тохины решения годны к строевай службе Никто не спорит, но имхо как аддоны к основной сути домино. Залогинислся, прописал в куки ID и потом его тереби, бань, и пр. Так собственно и сделано.

 

[ToxaRat]

NetWood
и в довесок, согласно лицензии домино клиентами считаются ВСЕ кто зарегистрирован в АК или использует аутентификацию доминошную
готовы ли вы за всех них платить?

 

[Akupaka]

согласно лицензии домино клиентами считаются ВСЕ кто зарегистрирован в АК или использует аутентификацию доминошную

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

 

[ToxaRat]

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

вы не поняли основу, в организации как в том же инет магазине может быть 3 человека а их клиенты это может быть и милион, какой тип лицензии вы посоветуете при такой ситуации?

 

[Akupaka]

как в том же инет магазине может быть 3 человека

Тоха, скажи мне, кто поставит себе в качестве сервера только для инет магазина домино да еще лицензионный!
Для подобных задач ставят мускуль с каким-нить бесплатным легким сервером.
к стати, просвяти меня тем пунктом лицензии, в котором указано написанное тобою :welcome:

 

[ToxaRat]

Akupaka
база клиентов и инет магазин во многом пересекаются

а с лицензией тут всё интереснее
приходит к тебе дядька с проверкой, глядит в свою книжку "как посчитать пользователей? - зайти в АК и выделить всех" - оп, тут ты и спалился