ggvне думал отвечать, но не удержался- парсеры блин на меня как красная тряпка на быка.

Сорри, не хотел злить.


Я ж уже писал выше про С-труктуры
Бинарный формат не надо забывать.

Я помню, про XDR. В хелпе Visual Studio .Net он связан везде с MSXML и написано, что это "XML Data-Reduced (XDR) is a subset of XML-Data". Насколько эффективно MS написал распарсивание его - ничего сказать не могу, может и эффективно. Однако ведь в этом случае все равно информация о типах передается в каждом сообщении? В то время как ODBC один раз передает информацию о том, какого типа будут поля (и сколько их) и после этого передаются только сами данные, в бинарном виде.


Уперлись все в этот гребанный XML, туды его в качель....
Это точно - передать список, например, имен - и тут же пихают XML, в то время как можно совсем просто сгенерить и разобрать его разделяя запятыми.

Я прошу прощения за назойливость, если вопрос не сложный и у вас есть время:
Схема все же получается, насколько я понимаю, правильная - у партнеров канал типа сендер, у нас ресивер. Схему на двух win серверах я протестировал. Сейчас дал реквизиты партнерам - будут пробовать настраивать. Единственное, что обескуражило - на предложение сказать им имя и пароль пользователя, под которым их пустит к нашему менеджеру или что бы они сказали под каким пользователем будут соединяться, они ответили, что никаких юзер ай-ди и паролей они не передают и у всех работает так. Должно ли так быть? Просто при тестовой конфигурации я заводил такого же пользователя на сервере-приемнике из под которого был запущен сервис на сервере-отправителе и вносил его (на сервере приемнике) в группу mqm (группа администраторов MQSeries). Поэтому думаю, что если их поля ааутентификации будут пустыми, то мой сервер им не даст ничего ложить в очереди. Прочитал, что вроде как-то можно разруливать политику на уровне менеджеров очередей с помощью OAM, но пока еще не нашел как.

NewYear
>что никаких юзер ай-ди и паролей они не передают и у всех работает так. Должно ли так быть

с MF на Workstation или OS/400 и обратно по умолчанию будет работать и так. почему не знаю.

Действительно работает. Даже и не знаю - радоваться ли этому факту или нет. Получается, что любой может закинуть в мою очередь сообщений...

NewYear
если among workstations/OS400 нужно чтобы пользователь из Identity Context
существавал на машине назначения.
+ см команду setmqaut.

Смотрю - может определить объекту права для определенных пользователей и групп. Вроде бы то, что надо. Единственное непонятно - передается ли серверами, кроме ай-ди юзера также и его пароль (а тогда в каком виде, тем более, что ОС/390 коннектится к в2к), ведь иначе любой может "притвориться" валидным юзером. Пока еще не прочел про это ничего.

NewYear
еще есть такая штука как MCA User Id. но это уже вспоминать нужно.

Попробую и про это почитать... :(

NewYear
>Поэтому думаю, что если их поля ааутентификации будут пустыми
это как? они что, руками забьют туда пустые значения и выставят Identity Context? что-то я сильно сомневаюсь...
Честно говоря, я не понимаю, может быть, глубин, но вот факт - поле User ID в пршиедших сообщениях пустое (во всяком случае его так показывает MQ Manager). В group id - нули, но это группа, насколько я понял не для секурности, а для объединения сообщений в группы.
Можно ли на МФ задать определенный контекст для определенного канала и, если можно, насколько это сложно?

ggvявно не прочитал указанную главу....прочитай when security checks are made
Ну, я прочитал про "setmqaut (set or reset authority)" и про "Chapter 20. Authorization service". Где почитать про "when security checks are made"? Или, может быть, я не все правильно перевел или что-то проглядел.

ggv
Нифига никакой пароль никуда нафиг не передается.

С трудом себе это могу представить. На каком-то уровне (пусть даже на уровне установки сетевого соединения) он ведь передается.
Еслия себе правильно представляю, то пароль передается даже не системе, а сервису, который "слушает" порт, а уже этот сервис может реализовывать свою систему безопасности (как это сделано в MS SQL Server 2000) либо пользоваться предоставляемым системой API для использования встроенной в ОС службой. MQSeries делает, насколько я понимаю, второй вариант.

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

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

ggv
То есть, если я тут у себя на соляре, к примеру, создам канал к вашему qmgr, создам qremote на вашу очередь.....

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

ggv
Если надо большего - Tivoli Directory Server, или Tivoli Access Manager, и внедряйте единую директорию, где все ваши юзвери и будут.
MQ Extended Security Edition как раз и есть симбиоз с Tivoly Access Manager
Ну, пока это не оправдано. Если нет простых вариантов, что бы MQ на МФ проходил аутентификацию в нашей ОС под специальным аккаунтом (т.е. назначал нашей очереди определенный Identity Context, если я, опять таки, правильно понимаю) - как это, например, делается в DB2 UDB под Windows, там ведь тоже аутентификация происходит через службу ОС, но при коннекте к конкретному экземпляру БД я могу указать логин и пароль. В общем, если таких вариантов нет, то тогда мы, наверно, просто закроем файрволом порт так, что бы на листенер этого менеджера мог коннектится только валидный МФ и локалхост... хотя лично мне этот вариант не очень нравится.

NewYear
контекст вообще-то для сообщений. MCA User ID тоже как-то влияет, забыл я :) кроме этого MCA User ID нет ничего.

Ну будем читать про MCA. Меня вот все же волнует точный механизм аутентификации - подробного описания я пока не нашел. А контекст можно задавать для каждого сообщения?

NewYear
покажи код программы на MF.
Я бы с удовольствием, но мне его никто не даст! :) У нас нет доступа к МФ вообще никакого. Во всяком случае - к этому.

2 New Year:
Попробую у партнеров узнать что у них там с кодом.

2 qqv:
Да, Вы правы. Пойду читать.

Вам обоим - большое спасибо!

2ggv:
Я не успеваю читать всю ту информацию, которую Вы успеваете посоветовать! :) Но все равно спасибо и я надеюсь ее прочесть.

Что касается безопасности, то я надеялся получить что-то похожее (хотя бы!!!) на реализацию аутентификации\авторизации в DB2 для Windows. В общем-то при коннекте сервер-сервер (на Win платформе) оно почти так и работает. Пересылающий сервер отсылает текущего win-пользователя\пароль, а принимающий обращается к системной службе безопасности, что бы провести аутентификацию, а с помощью setmqaut можно определить правила авторизации. Поскольку коннектится для пересылки сообщения именно канал, то мне казалось, что было бы логично дать возможность определять имя пользователя\пароль от имени которых канал будет запрашивать соединение. Если подобное можно определять на уровне сообщений, то это еще более гибко (особенно если можно определить поведение сервера источника в случае, если не все сообщения принимаются). Ну это я так думал. IBM думает совсем не так как я! :) Буду, значит, "учить матчасть". Спасибо, что есть такие люди как Вы и New Year, которые либо объяснят, либо носом в нужнуй документ ткнут, а то IBM настолько по своему думает, что я у них на сайте с трудом нахожу документацию, которая мне нужна. :)