Добрый день!
Кирилл, прошу прощения за неоконченный разговор, была занята.
Заказ по МБА/ЭДД наши коллеги предпочитают получать по электронной почте, т.е. нужен формат вывода отобранных данных в окно отправки почты роботом. Я предполагаю сделать ссылку на этот заказ в виде кнопки-картинки рядом с изображением принтера в результатах поиска.

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

Что касается заказа в АРМ Книговыдача, то я не предполагаю большого числа желающих. В настоящее время Заказ в АРМ Книговыдача поступает со страницы, но при выполнении заказа идет обращение в БД RDR, т.е. получить заказ можно, выполнять нельзя. Выхода из этой ситуации пока не вижу, но и необходимости решать проблему тоже, в любом случае выдачу документа делаем реальному пользователю, а он должен быть записан в RDR.

Галина Гильдебрант
Архангельская ОНБ

Gala написал(а):
-------------------------------------------------------

> Заказ по МБА/ЭДД наши коллеги предпочитают
> получать по электронной почте, т.е. нужен формат
> вывода отобранных данных в окно отправки почты
> роботом.

Как я понял, речь идёт об отправке выполненных заказов. "Отобранные данные" предполагается при этом использовать? О каком роботе в данном случае идёт речь?


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

Если пользователь сегодня идентифицирует себя как Иванов Иван Иванович, а завтра как Иванов И. И.(например) то во временной RDR базе у Вас будет две записи на одного и того же пользователя. Это типичная ситуация. Поэтому мне кажется целесообразным использовать специальную базу "Заказы", где в каждом случае будут фиксироваться данные пользователя. Если пользователь авторизован, можно брать данные из базы RDR.

Функционирующая сегодня в СЗТУ система электронной доставки практически целиком построена на основе команд WEB ИРБИС. Сегодня она морально устарела, и будет перерабатываться на PHP. Но положенные в её основу принципы по-прежнему актуальны для WEB ИРБИС. Поэтому, возможно, Вам окажется полезным доклад, сделанный по этому поводу на конференции Крым 2007.

Добрый день!
Возникли проблемы с авторизацией в полнотекстовом Web-ирбис 64 2009.1
При загрузке страницы поиска в полнотекстовых базах выдает ошибку

Error request!

и идет постоянный процесс ожидания ответа от сервера
(windows 2008, IIS 7 )
подскажите пожалуйста, в чем может быть причина

Вам целесообразно переустановить модуль.
Ошибка Error request! скорее всего связана с отсутствием необходимых данных в INI файле.

Кирилл Соколинский (СЗТУ) написал(а):
-------------------------------------------------------
> Вам целесообразно переустановить модуль.
> Ошибка Error request! скорее всего связана с
> отсутствием необходимых данных в INI файле.

Первым делом мы переустановили модуль - это не помогло, не могли бы выложить какие данные должны быть в ini файле и в каком месте и в каком именно ini файле

Пожалуйста:
1.Убедитесь, что базы располагаются на локальных дисках того сервера, где работает WEB ИРБИС.
2. Разместите на форуме cgi-bin\irbis_server.ini
3. Укажите адрес своего сайта
4. Перешлите на sokolinsky_k_e[sobaka]mail.ru cgiirbis_64.exe

> какие данные должны быть в ini файле и в каком месте и в каком именно ini файле

Секции с названием базы. Например, [text]



Редактировано 1 раз. Последний раз 21.05.2010 18:53 пользователем Кирилл Соколинский (СЗТУ).

Кирилл Соколинский
-------------------------------------------------------
> Пожалуйста:
> 1.Убедитесь, что базы располагаются на локальных
> дисках того сервера, где работает WEB ИРБИС.
> 2. Разместите на форуме cgi-bin\irbis_server.ini
> 3. Укажите адрес своего сайта
> 4. Перешлите на sokolinsky_k_email.ru
> cgiirbis_64.exe

Базы располагаются верно.Поиск по ним осуществляется правильно, осталась только авторизация,сайт в процессе разработки адреса еще нет,приложение cgiirbis_64.exe выслал на указанный адрес.

Кирилл Соколинский (СЗТУ) написал(а):
-------------------------------------------------------
> Я переслал Галине Гильдебрант специальную версию с
> возможностью использования альтернативной базы
> читателей. База авторизации может переопределяться
> параметром RdrName в секции Reader.
>
> Но смысл этого мне не совсем понятен… Для чего
> предполагается использовать базу RDR?…

Мы обсуждаем варианты реализации авторизации. Скажите пожалуйста сможем ли мы также сделать, чтобы авторизация шла по базе RDRV или нужны координальные изменения. Используем версию веб-ирбис 8.1

stasan написал(а):
-------------------------------------------------------

> Мы обсуждаем варианты реализации авторизации.
> Скажите пожалуйста сможем ли мы также сделать,
> чтобы авторизация шла по базе RDRV или нужны
> координальные изменения. Используем версию
> веб-ирбис 8.1

Для авторизации по любой базе отличной от RDR Вам требуется последняя модификация CGI WEB ИРБИС 91 или более поздней версии. Заменять используемые фреймы при этом не обязательно.

Прошу уделить мне немного внимания. Проблема с авторизацией WEB. Версия ПО 2009.1. Насколько я понимаю, фамилия берется из поля 10, пароль - из поля 22 (и, возможно, из 30).

Возникла необходимость создать новое поле (у меня оно получилось 24) и перенести туда все значения поля 22. То есть поле 22 сменило свое значение на 24. Само 22 поле теперь пустует и планируется, что в него будут записываться штрих-коды другой библиотеки. Мы хотитм сделать так, чтобы в наш веб могли заходить не только наши читатели, но и зарегистрированные у нас читатели другой библиотеки - отсюда и необходимость освободить для них 22 поле. Суть проблемы в том, что авторизация теперь не происходит для наших читателей, для которых отведено поле 24. Зато если ввести какое-нибудь значение в поле 22, то авторизация происходит, правда, читатель этот уже от другой, а не от нашей библиотеки...

Цель - обеспечить возможность регистрации читателей и по 22 и по 24 полю.

Подозреваю, что где-то надо также сменить/добавить какие-то значения. Подскажите где, в каком файле и что и как менять/добавлять. Спасибо!



Редактировано 1 раз. Последний раз 19.07.2010 15:07 пользователем StDemian.

Идентификатор читателя(пароль) по-умолчанию может находиться только в 30 поле!

Метка поля может быть изменена путём изменения значения параметра RQSTTAGREADER. Чтобы обеспечить возможность авторизации с использованием поля отличного от 30 требуется повторить в rdr.fst те строки, которые используются для индексирования 30 поля.

В случае применения префикса отличного от RI=, нужно изменить значение RdrPrefReader.

Авторизация с идентификаторами из разных полей не предусмотрена.

Кирилл, меня очень давно интересует вопрос: почему нельзя организовать авторизацию из нескольких полей или даже из другой базы? Что мешает сделать авторизацию по принципу ФЛК? К чему все эти сложности с жестко заданным полем и словарями? Пусть будет формат проверки авторизации и все вопросы, которые возникают уже на протяжении 7 лет, сразу же отпадут.

Уточню: в ходе самого процесса авторизации WEB ИРБИС ориентируется только на словарь, поэтому не имеет значения из каких полей термины-идентификаторы туда попадают. Но при заказе в RQST должна формироваться унифицированная запись, которая будет соответствовать стандартам АРМа Книговыдачи. И эта запись должна содержать только 1 идентификатор.

Поэтому, в принципе, можно авторизоваться на основе 30 и 3030 повторяющегося(например) поля, при том, что в запись RQST(параметр RQSTTAGREADER) будет попадать только одно поле.

По поводу авторизации-ФЛК. Максим, ты уже высказывал эту идею, но так и не раскрыл её и не ответил на мой вопрос.

1. Сейчас найду старое обсуждение. Как-то оно ничем закончилось.
2. Идентификация по словарю. Но ведь идентификация идет по 2 параметрам: имя и пароль. Значит одного только словаря не достаточно. Каков алгоритм в этом случае?
3. Заказ. Алгоритм заказа можно тоже не формировать статично в программе, а вынести его в ТВП, которая будет выполняться на текущей записи каталога + модельные поля из шлюза. На выходе аналог импорта в базу RQST.

Вот ссылка на прежнее обсуждение. Не последовало ответа по тому, что я просто не знаю, что можно ответить на такой вопрос. Ты прекрасно знаешь, как работает алгоритм CGIFLC в шлюзе. Только он проверяет корректность запроса пользователя. И если все хорошо, то дает дальше в шлюз перечень параметров запроса. Далее эти параметры обрабатываются на предмет авторизации. Вот тут тоже можно использовать формат для проверки авторизации. Если формат вернет пустую строку, то авторизация прошла, если же формат возвращает что-то, то это считается сообщением об ошибке авторизации. Как-то так я вижу это дело.

Панев Максим написал(а):
-------------------------------------------------------
> Вот ссылка на прежнее обсуждение. Не последовало
> ответа по тому, что я просто не знаю, что можно
> ответить на такой вопрос. Ты прекрасно знаешь, как
> работает алгоритм CGIFLC в шлюзе. Только он
> проверяет корректность запроса пользователя. И
> если все хорошо, то дает дальше в шлюз перечень
> параметров запроса. Далее эти параметры
> обрабатываются на предмет авторизации. Вот тут
> тоже можно использовать формат для проверки
> авторизации. Если формат вернет пустую строку, то
> авторизация прошла, если же формат возвращает
> что-то, то это считается сообщением об ошибке
> авторизации. Как-то так я вижу это дело.

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

Ну так уточни :). Приоткрой завесу авторизации. Кроме булевой операции там идет еще формирование шифра сессии. Если сделать в формате проверку, это шифр сессии или параметры авторизации, то все решится. Или я опять чего-то не знаю.

Шифра сессии, как и сессии не существует. Существует зашифрованный идентификатор записи читателя. Этот идентификатор используется для того чтобы быстро находить запись авторизованного пользователя. На записи авторизованного пользователя происходит выполнение всех форматов фреймов.(например, <? ?>, <!FORMAT=) Поэтому простого индикатора «читатель авторизован» или «читатель не авторизован» недостаточно.



Редактировано 1 раз. Последний раз 23.07.2010 13:36 пользователем Кирилл Соколинский (СЗТУ).

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

Если не возражаете, вклинюсь немного с другим вопросом, но по данном теме ветки.

Авторизация предоставляет возможность "показывать" или "не показывать" определенный код. Но меня интересует вот такая ситуация:

Есть эл. версии документов. Некоторые доступны могут быть всем. Некоторые доступны только читателям библиотеки. Делаю авторизацию, обрабатываю её при выводе ссылки на эл. версию документа. И получаю: для авторизованных выводит ссылку, для неавторизованных не выводит. Но эта ссылка все равно будет работать даже для неавторизованного читателя, если он её получит.

Вопрос: можно доступ к эл. версии (ссылка с параметром &IMAGE_FILE_NAME= ) ограничить дополнительно условием авторизации?

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

В CGIFLC этот случай можно легко обработать.

Да, это как раз тот случай, когда целесообразно использовать cgiflk.pft :)

Нужно добавить IMAGE_FILE_NAME в число поименованных параметров, назначив ему метку(например 5000) и далее в начало CGIFLK добавить такой код:
if p(v5000) and p(v2225) then '1' else '0' fi /
Не авторизованный пользователь выгрузить документ не сможет.

Можно проработать и более интересный вариант. Например, если в поле 6000 библиографической записи находится значение ‘ed_autorisation’, то документ можно выгружать только при условии авторизации.
Тогда код будет следующим:
if p(v5000) then if &uf('D',v3331,',|TEK=',v5000 ,'|,v6000')<>'' then
if p(v2225) then '1' else '0' fi
else
'1'
fi,
fi,/

Здесь предполагается, что значения IMAGE_FILE_NAME уникальны и могут выступать в роли идентификатора записи.

PS
Не сомневаюсь, Илья, что ты придумаешь, что-нибудь ещё более интересное, поэтому привожу лишь наброски кода.



Редактировано 2 раз. Последний раз 23.07.2010 13:38 пользователем Кирилл Соколинский (СЗТУ).

C CgiFlc до этого не сталкивался, но вроде понял что к чему. Попробую реализовать.

>Например, если в поле 6000 библиографической записи находится значение ‘ed_autorisation’

Подходящее поле в записях имеется. По нему как раз определяю "показывать" ссылку пользователю или нет.

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

На счет авторизации вопрос еще:

Авторизуюсь, и у меня в адресной строке видно "&Z21FAMILY=лазарев&Z21ID=9999" - это у меня где-то что-то не обновлено или так и должно быть? Вроде про шифрование этих данных был разговор.

И еще - какие именно должны преедаваться параметры в ссылках для сохранения авторизации при переходах по каталогу?

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

iLq написал(а):
-------------------------------------------------------
> На счет авторизации вопрос еще:
>
> Авторизуюсь, и у меня в адресной строке видно
> "&Z21FAMILY=лазарев&Z21ID=9999" - это у меня
> где-то что-то не обновлено или так и должно быть?
> Вроде про шифрование этих данных был разговор.

В версии 9.1 данные передаются через POST и в адресной строке не отображаются.
Шифрование идентификатора происходит после авторизации и зашифрованное значение идентификатора находится в виртуальном поле 2225.

При входе - все равно пишет. Даже на 9.1
Затем при переходах, да - не пишет.

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

Этого нет в последнем обновлении от 05.05.2010: [irbis.gpntb.ru]



Редактировано 1 раз. Последний раз 27.07.2010 00:37 пользователем Кирилл Соколинский (СЗТУ).

Кирилл, я попробовал добавить параметр:
#Имя файла
PARNAME40=IMAGE_FILE_NAME
PARTAG40=5000

В flc написал: if p(v5000) then '0/', else '1/' fi,
Это чтобы проверить. Но он меня по ссылке вида [terminal.vgu]
все равно пускает нормально.

Я что-то не так делаю?

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)

iLq написал(а):
-------------------------------------------------------
> Кирилл, я попробовал добавить параметр:
> #Имя файла
> PARNAME40=IMAGE_FILE_NAME
> PARTAG40=5000
>
> В flc написал: if p(v5000) then '0/', else '1/'
> fi,
> все равно пускает нормально.
>
> Я что-то не так делаю?

Слэш условного перевода строки у тебя оказался внутри литерала.

Кирилл, исправил на :
if p(v5000) then '0'/ else '1'/ fi,
if v3331='IBIS' then
'SCRIPT_DONE=YES',
fi

Все равно переходит на эл. версию без проблем, хотя как я понимаю, не должно. Делал проверку на другое поле - на туже авторизацию p(v2225) - работало. Может у меня поле 5000 как-то неверно зарегистрировано?

С уважением, Лазарев Илья (Научная Библиотека ВятГУ)



Редактировано 1 раз. Последний раз 29.07.2010 15:32 пользователем iLq.