Делаю трёхзвенку на базе SOAP.
В серверной части (SoapDataModule) к датасету(qrRead) привязываю TDataSetProvider где Exported=True...
Не значит ли это, что доступ к qrRead теперь будет открыт абсолютно всем желающим т.е. не только своим, но и чужим?
Если да, то как реализовать авторизацию при подключении к серверным DataSetProvider-ам?
В TSoapConnection есть свойства UserName и Password, но насколько я понял они относятся к Proxy

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

IMyAppServerSOAP = interface(IAppServerSOAP)
..
  function Logon(User, Password, Role: MyType): MyLogonResult;
..
end;

>http-авторизация
в качестве HTTP-сервера использую встроенный "индийский" (Indy) TIdHTTPWebBrokerBridge так что особо им не поуправляешь.

>в методах, которые требуют авторизации,
С этим все просто: в каждый такой метод добавить 2 параметра (юзер+пароль) или сессию

Вопрос в том как не подпустить чужаков к серверным DataSetProvider-ам?
Пока посматриваю в сторону OwnerData: OleVariant

>Сергей М.
а какое отношение "function Logon" имеет к доступности всем ветрам серверного DataSetProvider-а?

> DSKalugin ©   (10.11.08 17:06) [4]


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

цитата для Сергея из http://www.delphiplus.org/articles/delphi/soap_it_is_easy/

Основное условие при программировании SOAP: сервер должен быть stateless, т.е. результат выполнения запроса не должен зависеть от предыдущих команд, полученных сервером.
*********
нельзя одной командой передать параметры, а другой считать результат - все должно происходить в рамках одной команды

> [6] DSKalugin ©   (10.11.08 17:33)

SessionID = YourServer.LogonUser(...);

// some server method
function SomeMethod(ASessionID: integer; ...): integer;
begin
 if (ASessionID = 0) then begin
   Result := E_NOT_LOGGED_ON; //some constant
   Exit;
 end;
end;

как-то так

Речь не о методах, ёмаё...
Попробую перефразировать вопрос иначе
Есть клиентская часть


Серверная



на клиенте в коде пишу


запрос из cdsReader.CommandText передается по всей цепочке в серверный TDataSet где и выполняется

Так вот мне нужно каким-то образом закрыть доступ к TDataSetProvider-у чтобы он не обрабатывал "чужие запросы"

как видите ни методы ни тем более параметры этих методов тут не используются

> как видите ни методы ни тем более параметры этих методов
> тут не используются


Видим, "ёмаё".

Но что мешает "чужому" клиенту заполучить исключение




поскольку он не сделал




не видим. Ё-маё.

это все клиентский код, а что нужно сделать на сервере, чтобы
здесь


заполучить исключение?
ведь между


и


нет никакой связи т к Logon будет выполнен в одном серверном процессе, а отработка запроса - в другом, потому что SOAP работает как stateless

Ты не понял. Или я неправильно объяснил.
На стороне апп-сервера никаких исключений не будет.

Апп-сервер выполняя вызванный клиентом метод Logon осуществляет аутентификацию клиента, и в случае успеха экспортирует те дейтасет-провайдеры, с которыми клиент имеет право работать.


> soapDM.SoapConnection


Что-то я не понял, что у тебя делает клиентский компонент SoapConnection в дейтамодуле на стороне апп-сервера ?

> Что-то я не понял, что у тебя делает клиентский компонент
> SoapConnection в дейтамодуле на стороне апп-сервера ?

да нет, это как раз-таки клиентский код.

Но я бы вообще отказался от прямого задания запроса через CommandText на стороне клиента. А делал бы все через методы, передавая имя провайдера

soapDM.SoapConnection у меня на клиенте, естественно см (10.11.08 18:40) [8]

Да, что-то мы недопонимаем друг друга. В этом и есть недостаток электронного общения ;-)

Вопрос решен так (пока что)


тобишь одним действием и авторизация и получение данных

> clickmaker ©   (11.11.08 11:05) [12]


Я может и мартышка к старости, но читать пока не еще разучился)

Читаю справку:

Use a TSoapDataModule object as the central repository for all objects in a SOAP-based application server.
Typically these are data access components, such as datasets and the provider components that handle communication between these datasets and client applications

Просматриваю демо-проекты:

Search for 'TSoapDataModule'
 C:\Program Files\Borland\Delphi7\Demos\WebServices\EchoService\Server\DataMod_U.pas(13):   TDataMod = class(TSoapDataModule, IDataMod, IAppServer)
 C:\Program Files\Borland\Delphi7\Demos\WebServices\SOAPDataModule\Server\DataMod_U.pas(14):   TDataMod = class(TSoapDataModule, IDataMod, IAppServerSOAP)
 C:\Program Files\Borland\Delphi7\Demos\WebServices\SOAPDataModule\Server\SOAPDMServerCGI.dpr(8):   DataMod_U in 'DataMod_U.pas' {DataMod: TSoapDataModule},
 C:\Program Files\Borland\Delphi7\Demos\WebServices\SOAPDataModule\Server\SOAPDMServerWAD.dpr(10):   DataMod_U in 'DataMod_U.pas' {DataMod: TSoapDataModule};

Нигде не вижу упоминаний того, что TSoapDataModule используется на клиентской стороне распределенного midas-приложения.

> [14] Сергей М. ©   (11.11.08 11:40)

да у него там может и обычный DataModule быть. Просто как контейнер для датасетов

> Просто как контейнер для датасетов


A зачем его тогда обзывать soapDM ?


> тобишь одним действием и авторизация и получение данных


Кривовато, но суть одна и та же, что и при использовании специально реализованного метода аутентификации.

TsoapDM. (клиентский ДМ, работающий с соап-ом)<> TsoapRDM. (серверный)

да уж действительно названия датамодулей подобрал почти одинаково (неудачно)

Удалено модератором

Удалено модератором