Проблема в том что в АРМ Книговыдача заказ приходит в таком виде, что в поле "Читатель" приходит та информация, которую я подаю в Web-Ирбис в качестве пароля, а мне для соблюдения традиций хотелось бы чтобы туда попадал как и прежде номер читательского из поля 30. Так, чтобы девушки на выдаче даже не знали что где-то там что-то изменилось.

В своих изысканиях дошел до фрейма order_form.frm - дальше тупик

Цитата:

order_form.frm
<td valign="Top"><input name="Z21ID" type="password" size="40"><br>

не понятно что происходит дальше при SUBMIT: очевидно, что это значение будет с чем-то сверяться так как оно является паролем подтверждения заказа, а как-будто именно в него мне надо положить номер читательского из поля 30

Если я правильно понял, незашифрованый номер читательского из поля 30 хранится после авторизации в поле 1002, но как его подсунуть в заказ?

сделайте поле скрытым и заполните
<td valign="Top">

<input name="Z21ID" type="hidden" value="<? &uf('dRDR,!RI='v1002'!,v30') ?>">
type="hidden" - скрывает поле ввода

<? ?> - говорит о том что внутри будет формат
&uf('dRDR,!RI='v1002'!,v30') - запрашиваем из бд rdr по префиксу RI= и термину - содержимое v1002 идентификатор читателя из поля 30

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Цитата:

GLUKa
<input name="Z21ID" type="hidden" ...
type="hidden" - скрывает поле ввода

Это да, но разве в этом случае не придёт отказ в авторизации в виду того, что данные этого поля по совместительству - пароль? Доберусь до сервера надо будет еще раз внимательно посмотреть как там происходит повторная авторизация

Т.е. мы туда подставляем данные которые хотим и они уходили бы в заказ, но вместо этого заказ вообще не оформляется так как те данные которые мы туда положили сравниваются с эталонным паролем и не совпадают, в результате чего заказ не офорляется вообще. Я так (на своем обывательскому уровне) это представляю



Редактировано 1 раз. Последний раз 07.12.2023 23:25 пользователем Андрей Владимирович (Библиотека УрГУПС).

ну так я же вам предлагаю сразу заполнять поле
Андрей Владимирович (Библиотека УрГУП написал(а):
-------------------------------------------------------
> <input name="Z21ID" type="hidden" ...
> type="hidden" - скрывает поле ввода
>
> Это да, но разве в этом случае не придёт отказ в
> авторизации в виду того, что данные этого поля по
> совместительству - пароль? Доберусь до сервера
> надо будет еще раз внимательно посмотреть как там
> происходит повторная авторизация
>
> Т.е. мы туда подставляем данные которые хотим и
> они уходили бы в заказ, но вместо этого заказ
> вообще не оформляется так как те данные которые мы
> туда положили сравниваются с эталонным паролем и
> не совпадают, в результате чего заказ не
> офорляется вообще. Я так (на своем обывательскому
> уровне) это представляю

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Добавил пару скринов чтобы читателю было проще представлять о чем я говорю

Результаты сегодняшних изысканий:
1. Выяснилось, что в поле 1002 кладутся не данные из поля 30 той записи читателя, которая совпала при первичной авторизации, а собственно сами данные из поля пароля из deposit/not_author_3.frm
2. Если поискать по аналогии с вашим предложением, идентификатор читателя действительно находится, но заказ не осуществляется т.к. повторная авторизация для совершения заказа проваливается (как я и предполагал) с выводом строки из WebMSG.txt: "ОШИБКА ПРИ РЕГИСТРАЦИИ ЧИТАТЕЛЯ"

В связи с чем такие вопросы
1. Знает ли вообще (Web-)ИРБИС MFN записи из базы читателя, данные из которой совпали при первичной идентификации (submit в not_author_3), или идентификатор этого читателя. Было бы проще оперировать ими чем обратно запрашивать в базе информацию по этому читателю.
Не возникает понимания механизма авторизации. При одинаковых фамилиях и разных "паролях" система же как-то определяет кто из Ивановых перед ней - как? И где она потом хранит эти данные в каких полях
2. Боюсь, что механизм этой второй авторизации "зашит" в коде и мы не можем повлиять на его работу. Так ли это? Если так придётся или упразднять повторную авторизацию при заказе, чего не хотелось бы так как есть терминалы с общим доступом в электронный каталог (станут появляться заказы на "прошлых" пользователей терминала) или как-то еще её обманывать типа включать данные идентификаторов читателей в словарь поля по которому хочу сделать новую авторизацию или включать данные моего нового поля в словарь идентификаторов читателей

Вообщем посыл сверху такой: читатель может не знать свой идентификатор, а должен иметь возможность идентифицировать себя по этому новому полю (вместо старого способа идентификации или в дополнение к нему), но в АРМ Книговыдача всё должно выглядеть так как будто ничего не менялось. Всю голову сломал.



Редактировано 2 раз. Последний раз 08.12.2023 16:48 пользователем Андрей Владимирович (Библиотека УрГУПС).

если читатель не авторизован. то для того чтобы сделать заказ .он должен пройти авторизацию. И ка я вижу у Вас какая то очень старая версия САБ ИРБИС

Андрей Владимирович (Библиотека УрГУП написал(а):
-------------------------------------------------------
> Добавил пару скринов чтобы читателю было проще
> представлять о чем я говорю
>
> Результаты сегодняшних изысканий:
> 1. Выяснилось, что в поле 1002 кладутся не данные
> из поля 30 той записи читателя, которая совпала
> при первичной авторизации, а собственно сами
> данные из поля пароля из deposit/not_author_3.frm
>
> 2. Если поискать по аналогии с вашим предложением,
> идентификатор читателя действительно находится, но
> заказ не осуществляется т.к. повторная авторизация
> для совершения заказа проваливается (как я и
> предполагал) с выводом строки из WebMSG.txt:
> "ОШИБКА ПРИ РЕГИСТРАЦИИ ЧИТАТЕЛЯ"
>
> В связи с чем такие вопросы
> 1. Знает ли вообще (Web-)ИРБИС MFN записи из базы
> читателя, данные из которой совпали при первичной
> идентификации (submit в not_author_3), или
> идентификатор этого читателя. Было бы проще
> оперировать ими чем обратно запрашивать в базе
> информацию по этому читателю.
> Не возникает понимания механизма авторизации. При
> одинаковых фамилиях и разных "паролях" система же
> как-то определяет кто из Ивановых перед ней - как?
> И где она потом хранит эти данные в каких полях
> 2. Боюсь, что механизм этой второй авторизации
> "зашит" в коде и мы не можем повлиять на его
> работу. Так ли это? Если так придётся или
> упразднять повторную авторизацию при заказе, чего
> не хотелось бы так как есть терминалы с общим
> доступом в электронный каталог (станут появляться
> заказы на "прошлых" пользователей терминала) или
> как-то еще её обманывать типа включать данные
> идентификаторов читателей в словарь поля по
> которому хочу сделать новую авторизацию или
> включать данные моего нового поля в словарь
> идентификаторов читателей
>
> Вообщем посыл сверху такой: читатель может не
> знать свой идентификатор, а должен иметь
> возможность идентифицировать себя по этому новому
> полю (вместо старого способа идентификации или в
> дополнение к нему), но в АРМ Книговыдача всё
> должно выглядеть так как будто ничего не менялось.
> Всю голову сломал.

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Цитата:

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

Да, но при совершении заказа, читатель должен повторно ввести "пароль" чтобы подтвердить заказ.

Цитата:

GLUKa
И ка я вижу у Вас какая то очень старая версия САБ ИРБИС

Что есть - то есть. Даже в заголовке об этом написал

Для того чтоб повторно не вводить. я вам изменения. выше написала

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

Проблема не в том, что нужно или не нужно повторно вводить это значение, а в том что это значение одновременно и сверяется на правильность как пароль, и поступает в заказ в качестве сведений о читателе (а оттуда поступает в АРМ Книговыдача)

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

Вижу два пути достижения цели:
1) модифицировать проверку пароля таким образом, чтобы значение которое мы хотим видеть в заказе подходило как пароль. Достигается модификацией словаря (чтобы в качестве пароля подходило и значение из поля 30, и значение из моего поля) + подменой значения в фрейме, но каким-то более хитрым образом (брать данные из поля пользовательского ввода и пересчитывать по мере ввода?)

2) модифицировать механизм формирования заказа таким образом, чтобы после того как значение проверилось как пароль и подтвердило авторизацию пользователя, в заказ приходило замененное значение, которое никого не смутит в АРМ Книговыдача. Не вполне представляю как такое можно реализовать. Самое ближайшее что походило бы это механизм автоввода, но он наверняка не используется в этих процессах в базе RQST

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



Редактировано 2 раз. Последний раз 11.12.2023 12:59 пользователем Андрей Владимирович (Библиотека УрГУПС).

хотите другие пути решения. с разделением пароля и поля 30 с возможностью смены пароля и т.д. обновитесь до более свежей версии

Андрей Владимирович (Библиотека УрГУП написал(а):
-------------------------------------------------------
> Проблема не в том, что нужно или не нужно повторно
> вводить это значение, а в том что это значение
> одновременно и сверяется на правильность как
> пароль, и поступает в заказ в качестве сведений о
> читателе (а оттуда поступает в АРМ Книговыдача)
>
> Избавляться от повторной авторизации не следует -
> она там не для красоты, она для того, чтобы
> избежать ситуации когда один читатель бросил
> открытой свою учётку в терминале общего
> пользования и ушел, а следом за ним подошел другой
> читатель к терминалу и заказал литературу на имя
> первого (ушедшего) читателя.
>
> Вижу два пути достижения цели:
> 1) модифицировать проверку пароля таким образом,
> чтобы значение которое мы хотим видеть в заказе
> подходило как пароль. Достигается модификацией
> словаря (чтобы в качестве пароля подходило и
> значение из поля 30, и значение из моего поля) +
> подменой значения в фрейме, но каким-то более
> хитрым образом (брать данные из поля
> пользовательского ввода и пересчитывать по мере
> ввода?)
>
> 2) модифицировать механизм формирования заказа
> таким образом, чтобы после того как значение
> проверилось как пароль и подтвердило авторизацию
> пользователя, в заказ приходило замененное
> значение, которое никого не смутит в АРМ
> Книговыдача. Не вполне представляю как такое можно
> реализовать. Самое ближайшее что походило бы это
> механизм автоввода, но он наверняка не
> используется в этих процессах в базе RQST
>
> Оба пути не вполне меня устраивают так как новое
> поле неуникальное, и нужно теперь понимать как
> система делает авторизацию по неуникальной фамилии
> чтобы думать смогу ли я сделать это по своему
> неуникальному полю. Пара "фамилия - моё поле" всё
> еще является уникальной комбинацией.

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ