Авторизация в вебсервисах

← →
Тимохов Дима © (2016-09-12 15:12) [0]

Коллеги!

1. Вебсервисами пользовался. Опыт есть. Брал ставки ИПС с адреса http://www.cbr.ru/secinfo/secinfo.asmx. Но там не было никакой авторизации.
Т.е. с авторизацией в вебсервисах не работал!

2. Сейчас третья сторона срочно требует ответ по стратегии интеграции.
В частности, есть вопросы по авторизации:
<<Так же прошу учесть, что авторизацию я планирую делать по Active Directory.
Это удобно? Если нет, можно сделать простой логин и пароль.>>

3. Вопрос. Как вообще устроена авторизация в вебсервисах? Где-то читал, что вроде как на уровне вебсервисов это не решено.
Или надо авторизацию делать через HTTP, на который опирается вебсервис?

Заранее спасибо!

← →
ВладОшин © (2016-09-12 16:29) [1]

Не знаю про то ли это
.. тебе wsdl, ты подсовываешь delphi ее, генерируются все необходимые классы и типы... если про то, то у меня так авторизация (delphi 6 )
(судя по http в именах, через http и делается, похоже что)

function GetOrdersPortType(aUserName, aPassword: string; UseWSDL: Boolean; Addr: string; HTTPRIO: THTTPRIO): OrdersPortType;

// генерируется ide, что-то правил именно про логин/пароль, не помню что- в основном код уже такой автоматом
const

defWSDL = "C:\delphi_work\orders\скаченный wsdl.wsdl";
defURL = "https://ссыль к ним/ws/orders";
defSvc = "Orders";
defPrt = "OrdersS";
var
RIO: THTTPRIO;
begin
Result := nil;
if (Addr = "") then
begin
if UseWSDL then
Addr := defWSDL
else
Addr := defURL;
end;
if HTTPRIO = nil then
RIO := THTTPRIO.Create(nil)
else
RIO := HTTPRIO;

RIO.HTTPWebNode.UserName := aUserName;
RIO.HTTPWebNode.Password := aPassword;

try
Result := (RIO as OrdersPortType);
if UseWSDL then
begin
RIO.WSDLLocation := Addr;
RIO.Service := defSvc;
RIO.Port := defPrt;
end else
RIO.URL := Addr;
finally
if (Result = nil) and (HTTPRIO = nil) then
RIO.Free;
end;
end;

← →
Eraser © (2016-09-12 17:20) [2]

> Тимохов Дима © (12.09.16 15:12)

в принципе, Indy поддерживает и один и другой тип авторизации.

← →
Тимохов Дима © (2016-09-12 17:43) [3]

> ВладОшин © (12.09.16 16:29) [1]

Посмотрел.
HTTPWebNode - реализован поверх WinINe.
Т.е. я чего хочу сказать - что тут речь, про то, что авторизация идет не на уровне SOAP, а на более низком уровне HTTP. А на уровне SOAP как таковом авторизации нет? Верно?

> Eraser © (12.09.16 17:20) [2]
> > Тимохов Дима © (12.09.16 15:12)
> в принципе, Indy поддерживает и один и другой тип авторизации.

Тут, понимаешь, вопрос даже немного теоретический.
Я правильно понимаю, что авторизация идет на уровне HTTP, а не на уровне SOAP как такового?

← →
Eraser © (2016-09-12 17:53) [4]

> Тимохов Дима © (12.09.16 17:43) [3]

насчет NTLM точно сказать не могу, возможно есть разные варианты реализации, но что касается basic и digest, то это именно в стандарте предусмотрено http://www.ietf.org/rfc/rfc2617.txt

← →
sniknik © (2016-09-12 19:02) [5]

> что авторизацию я планирую делать по Active Directory.
> Это удобно?
это невозможно. авторизация подразумевает логон в систему с логином-паролем, а Active Directory это просто "база" данных по учеткам, и т.д. не система, дополнение, в котором можно посмотреть данные любой учетки (если прав у текущей хватит), но не авторизоваться.

> Как вообще устроена авторизация в вебсервисах?
сервер в винде будет? ну так проверяй результат LogonUser (логин в винду, будет виндовая) на сервере типа: (юзер и домен раздельно, выделяются из прислаонного)
if not LogonUser(PChar(User(ARequestInfo.AuthUsername)), PChar(Domain(ARequestInfo.AuthUsername)), PChar(ARequestInfo.AuthPassword ), LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, um) then begin AResponseInfo.AuthRealm := "Login"; AResponseInfo.ResponseText:= "test"; Exit; end;

← →
ВладОшин © (2016-09-12 20:39) [6]

> Тимохов Дима ©
на более низком уровне HTTP

видимо так

← →
Игорь Шевченко © (2016-09-12 22:33) [7]

> с авторизацией в вебсервисах не работал

А в чем проблема ? Вот ты на этом сайте как-то авторизуешься, веб-сервис несильно отличается. Я со своей дилетантской колокольни полагаю, что ты перед началом использования функций, требующих авторизации, передаешь методу авторизации веб-сервиса credentials пользователя, она тебе возвращает некий его идентификатор (cookie), и ты этот идентификатор используешь в запросах к тем функциям, которые требуют авторизованного доступа.

← →
Тимохов Дима © (2016-09-13 11:37) [8]

> sniknik © (12.09.16 19:02) [5]

Ты не мог бы пояснить подробнее о чем речь тут?
Не могу врубиться в то, что сказал...

> > Как вообще устроена авторизация в вебсервисах?
> сервер в винде будет? ну так проверяй результат LogonUser
> (логин в винду, будет виндовая) на сервере типа: (юзер и
> домен раздельно, выделяются из прислаонного)

> Игорь Шевченко © (12.09.16 22:33) [7]

Да вроде как на уровне уже вызовов веб-сервиса никаких авторизационных действий нет - методы это просто методы с параметрами. А вот вся авторизация идет ниже. Пока я понял, что на уровне HTTP.

← →
iop © (2016-09-13 11:54) [9]

это невозможно.

это возможно. иногда.

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

← →
iop © (2016-09-13 11:55) [10]

но опять таки это никак не связано с "авторизацией в вебсервисах"

> iop © (13.09.16 11:55) [10]
> но опять таки это никак не связано с "авторизацией в вебсервисах"

Я думаю, что сотрудник с той стороны подразумевает, что в его интранет-сервер, реализующий вебсервис, просто будут добавлены юзера с паролями из Active Directory. И я должен буду, при реализации HTTP-авторизации, передавать юзера и текущий пароль (откуда его брать только не знаю).
Спросил. Жду, чего ответит.

они всегда что-то подразумевают. и всегда что-то хотят не обязательно совпадающее с подразумеваемым.

веб сервис на пальцах если - самый обычный веб-ресурс на который могут не пускать анонимно. абсолютно точно так же как и к фотке с котиками.

плюс сам этот веб-ресурс-веб-сервис может иметь параметры логина/пароля в своих сугубо вебсервисных методах.

добавить если, то круче
"послать набор байт на удаленный порт"
не придумали еще )

сервисы-шмервисы.. все равно им на 80(если не переопределено) й порт шлёпнется что-то вроде s : string = "http 1.0 Content-Type: application/x-www-form" и т.п.
откуда прилетит Cookie: твоя сессия ["{B3DA3A91-5CEC-4A52-AE8C-924D00C40E3A}"]
и потом ты неявно всегда postом шлёшь еще один параметр
s : = s + Cookie, подтверждая, что ты это ты.
ну, или 150 параметров )

и все эти soap, библиотеки - просто некое форматирование этой строки s : string
что наглядно можно доказать, формируя текст запроса именно простым s := s +

как то понадобилось на какой то сервер тоже лазить, пишу им узнать как должно быть, какой обмен - какой IN|OUT - ничего не понял в итоге, какие-то версии какой-то библиотеки надо поставить пишут..
В снифере посмотрел обмен, сформировал s := s + и Port.Send(s);
Когда что-то приходит, распарсиваю и s := s +ЧтоВернулось + и Port.Send(s);
в общем, обычный TTCPClient вполне работает.
Безусловно, неудобно. Но.. вот прям ща я буду ставить эти библиотеки, php и прочее, ради одного запроса в сутки..

В общем решилось в итоге так:
1. Компьютер, где стоит IIS, добавлен в Active Directory.
2. Юзер и пароль будут передаваться в ходе NTLM авторизации.
От меня вообще ничего не требуется. Они все сами настроят.

Всем спасибо)

ЗЫ От вебсервисов вообще, кстати, отказались - будет HTTP GET-запрос с параметрами через URL с возвратом XML.

ЗЗЫ Пока ответа ждал наваял себе тестовый вебсервис и клиента к нему с передачей любых данных (в т.ч. и XML). Клево это в дельфи сделано! Жаль, что раньше не приходилось работать.
С удивлением обнаружил хорошую статью для старта на этом же сайте http://www.delphimaster.ru/articles/web_delphi/index3.html
Может, полезно будет.

очень полезно.

особенно с учетом того, что будет гет с xml в респонсе, статья помогает избежать ужасно длинного кода

with CoDomDocument.Create do
begin
async := false;
if load(<get_url>) then ShowMessage(xml);
end

Авторизация в вебсервисах Найти похожие ветки