Кастомизация
11
Мар
9

Поле-пароль

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

  • Для начала необходимо запомнить исходную информацию, находящуюся в целевом поле. Поместим ее в глобальную переменную. Затем «зашифруем» значение целевого поля, поместив в него символы «x» в количестве, эквивалентном количеству букв в исходной строке. Вешаем на онлоад:
    document.securefield = function() {
    	// Проверяем что секретное поле содержит данные
    	if (crmForm.all.new_securefield.DataValue) {
    		// Запоминаем исходное значение
    		document.originalvalue = crmForm.all.new_securefield.DataValue;
    		// Формируем строку "xxxxx" в соответствии с количеством символов в исходной строке
    		document.secret = "";
    		for (i=1;i<=crmForm.all.new_securefield.DataValue.length;i++) {
    			document.secret += "x";
    		}
    		// Заменяем исходную строку шифром
    		crmForm.all.new_securefield.DataValue = document.secret;
    		// Задаем для текста секретного поля черный цвет (необходимо т.к. после сохранения текст перекрашивается в белый цвет)
    		crmForm.all.new_securefield.style.color = '#000000';
    	}
    }
    
    document.securefield();
    

    Помимо этого помещаем всю логику в глобальную функцию, чтобы потом ее можно было вызвать с события onSave;

  • Когда юзвер закончит редактирование карточки, он попытается ее сохранить ее. И чтобы вместо нормальной строки в базу данны не попали xxxxx, необходимо вернуть в целевое поле исходные данные. Поэтому вешаем на онсейв:
    // Если секретная строка не менялась, то заменяем ее исходным значением
    if (crmForm.all.new_securefield.DataValue == document.secret) {
    	// Перекрашиваем текст в белый цвет, чтобы из-за задержки сохранения пользователь не "подглядел" исходную строку
    	crmForm.all.new_securefield.style.color = '#FFFFFF';
    	// Заменяем секретную строку исходной
    	crmForm.all.new_securefield.DataValue = document.originalvalue;
    	// На случай если пользователь нажал кнопку Сохранить, то снова шифруем ее
    	document.securefield();
    }
    


Комментарии (9)
  • Vladislav Osmanov 11.03.2010

    А потом другой пользователь жмёт кнопку «Печать» и видит пароль открытым текстом на форме печати…

    Ну, или расширенный поиск…

    Текущая версия Microsoft Dynamics CRM не поддерживает т.н. field level security и для таких сценариев предлагается заводить отдельную сущность (она будет хранить секретное значение), привязывать её к основной сущности и на уровне ролей безопасности раздавать права обычным и привелегированным пользователям. Данная реализаци не всегда удобна.

    Предлагаю следующий вариант: в поле с паролем хранить не его _значение_, а _хэш_ (HMAC с помощью хэш-функции SHA1, в библиотеке классов .NET есть для этого тип HMACSHA1). Значение этого хэша никому не интересно, его можно, разве что, только «испортить» или удалить, но сам пароль так и останется неизвестным.

    Есть реализация вышеописанного в Microsoft Dynamics CRM, попробую на выходных описать у себя : )

  • Vladislav Osmanov 11.03.2010

    А! И первый вариант, того, как скрыть пароль, который пришёл на ум, подменить поле с паролем на INPUT type=password (http://msdn.microsoft.com/en-us/library/ms535837(VS.85).aspx). Всё остальное сделает IE.

  • slivka_83 11.03.2010

    Добрый день 🙂

    1. Ни на какой field level security данный сценарий не претендует 🙂 его также можно «сломать» JavaScript’ом через строку браузера 🙂 это так… «защита от дураков» 🙂
    2. А дальше то что с хэшем делать? Секретности требуют не только пароли 🙂 Если я не ошибаюсь какуюе-либо строку можно однозначно перевести в хэш, а вот хэш уже в свою очередь нельзя однозначно перевести в исходное значение 🙂 Поэтому мы не можем хранить только хэш 🙂
    3. А вод про type=password уже интереснее, но вот как это рализовать, что-то не очень себе представляю 🙂 К тому же, как опят таки реализовать это на всех формах и в расширенном поиске и на печатной форме и т.д. 🙂

  • Vladislav Osmanov 11.03.2010

    Добрый : )

    Ответ тут: http://crrm.ru/articles/2010/03/secure-pass-storing-in-mscrm

    > 2. А дальше то что с хэшем делать?
    В том-то и дело, что ничего с ним дальше не надо делать. С ним можно сравнивать другие хэш-значения, и если они совпадают, то и секретные значения для этих хэшей равны (коллизии не рассматриваем).

    Хеширование паролей — частный случай. На самом деле, в криптографии с открытым ключом, хеширование предназначено для представления большого объёма данных в «сжатом» виде, и используется для проверки целостности, аутентификации и предотвращения отказа от обязательств при цифровой подписи.

  • Юлия 11.03.2010

    Добрый день! Приношу заранее извинения, что вопрос не в тему, но очень надеюсь на вашу помощь…
    Возникла проблема с вложениями! При отправке письма из Outlook с включенным отслеживание в CRM, вложения приходят пользователям в формате winmail.dat!!! При отправке писем с отключенным CRM, вложения приходят в нормальном виде!!! Поэтому я подозреваю, что проблема именно в настройках CRM, а где и как это исправить самостоятельно мне не удалось найти!
    Возможно существуют еще варианты решения данной проблемы? Как от этого избавиться и сделать, чтобы вложения приходили в обычном формате???

  • slivka_83 11.03.2010

    Вот тут описана Ваша проблема: http://social.microsoft.com/Forums/en-US/crm/thread/dc9a7b09-237d-42d7-afa6-27a1de2be6df
    Как следует из текста, это касяк Outlook’а. В конце приводится воркэраунд с помощью макроса 🙂 можете попробовать 🙂

  • Vladislav Osmanov 11.03.2010

    Юлия, добрый вечер.

    Попробуйте обновить:

    1. Клиент Microsoft Dynamics CRM для Microsoft Outlook (на клиентских компьютерах пользователей) — файл «CRMv4.0-KB977650-i386-Client-LangID.exe»

    2. Email Router (служба на сервере CRM или Exchange) — файл «CRMv4.0-KB977650-i386-Router-LangID.exe»

    3. Скорее всего потребуется обновить и сервер: CRMv4.0-KB977650-i386-Server-ENU.exe

    Обновления тут (Rollup 9, не забудьте выбрать нужный язык): http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5869f2b3-d1a0-4f71-8be3-fde6e8053a2e

    Обязательно опишите результат.

  • Фарид 11.03.2010

    2Юлия: у меня аналогичная проблема и кажется мы с вами уже пересеклись тут http://social.technet.microsoft.com/Forums/ru-RU/dynamicsru/thread/8dd71563-8f01-4705-b344-d08400dd6804?ppud=4

    2slivka_83: попробовать то можно, денег только на их компоненту кто-нибудь дал))) 7000р. отдавать за использование 1-ой ф-ции в компоненте не разумно

    2Vladislav Osmanov: Ваш вариант не сработал к сожалению

  • Евген 11.03.2010

    У меня такая же проблема, как у Фарида и Юлии — некоторые сообщения с вложениями от нас доходят до клиентов с вложением типа winmail.dat. пробовал апдейты сервера, роутера, оутглюк-клиента — когда как, то все нормально, то нет. не могу отследить закономерность.

*

code