Коллеги, приветствую.
Возник вопрос по ведению и хранению паролей в Z таблице. Как зашифровать пароль - это все умеем, там свой алгоритм. меня интересует, можно ли сгенерировать ракурс ведения к таблице, чтобы в поле (пусть будет)"Пароль" выводились "*", а не то, что вбивает юзер.
Вторая часть - это хранение. После того как юзер ввел пароль, его нужно зашифровать и переложить в другое поле этой же таблицы(пусть будет имя "Хэш"), а из поля "Пароль" значение потереть. Есть идея, что эта часть делается через события, иначе править генереный код придется.
Есть какие нибудь предположения по этим вопросам?

А чем саповские пароли провинились?

В свойствах поля убрать галочку "поле вывода" или в PBO-логике экрана для поля установить SCREEN-OUTPUT = 0. Событиями это не сделаешь.

Событие 01 или 08
Но лучше для ведения паролей сделать отдельную транзакцию, над экраном которой можно поработать вручную.

Не провинились. Это пароли для авторизации на сервере через вебсервис.


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


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

screen-invisible = 1

Что за задача такая, что пароль должен храниться в SAP-системе?


В Генераторе ведения таблиц пункт меню "Среда-Модификация-Экраны ведения".

Нередко разработка и сопровождение Z-программы менее геморный процесс, чем впихивание такой программы в стандратное САПовское средство.

--Не провинились. Это пароли для авторизации на сервере через вебсервис.

У нас по другому сделано: на телефон что прописан на пользователе отправляется СМС со сгенерированным(каждый раз новым) паролем.

А для отправки смс используется интернет шлюз?

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

Вообще, если честно, изначально в задаче этих пользователей не было... они появились позже, когда заказчик все-таки понял, что он хочет. как всегда, собственно

По-хорошему на стороне SAP их не нужно.
Достаточно на стороне web-сервиса проводить авторизацию и корректно формировать условия выборки.
По крайней мере мы так у себя планируем сделать.

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

Ну если заказчик бюджет увеличил - то любой каприз за его деньги
Как вариант - выдавать каждому пользователю свою учетную запись в SAP.
Это намного более защищенный вариант

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