Перейти к основному содержимому Перейти к дополнительному содержимому

Управление безопасностью данных с помощью Section Access

Section Access используется для управления безопасностью приложения. Практически это часть скрипта загрузки данных, в которую добавляется таблица безопасности, определяющая, кто что может просматривать. Qlik Cloud использует эту информацию для сокращения объема данных до соответствующей области, когда пользователь открывает приложение, то есть часть данных в приложении будет скрыта от пользователя в зависимости от его удостоверения. Section Access тесно интегрирован с данными в приложении и полагается на них для управления доступом. Эта форма динамического сокращения данных может предназначаться для строк таблицы, столбцов таблицы или их комбинации. Для получения дополнительной информации см. раздел Доверие и безопасность в Qlik.

Разделы в скрипте загрузки

Управление доступом к данным осуществляется с помощью одной или нескольких таблиц безопасности, загруженных так же, как обычно загружаются данные. Таким образом, эти таблицы можно хранить в стандартной базе данных или в электронной таблице. Операторы скрипта, управляющие таблицами безопасности, даны в секции авторизации, которая в скрипте запускается оператором Section Access.

Примечание к информации

Все имена полей и значения полей, перечисленные в Section Access, всегда преобразуются в верхний регистр. В результате все поля, участвующие в сокращении количества данных, должны быть преобразованы в верхний регистр для приведения в соответствие с содержимым оператора Section Access, даже если они находятся вне оператора Section Access. Имя любого поля с буквами в нижнем регистре в базе данных можно преобразовать в верхний регистр с помощью функции Upper до чтения поля с помощью оператора LOAD или SELECT.

Для получения дополнительной информации см. раздел Upper — функция скриптa и диаграммы.

Если в скрипте определена секция авторизации, то часть скрипта, загружающая данные приложения, должна быть помещена в другой раздел, запускаемый оператором Section Application.

Пример:  

Section Access; Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ];Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 ADMIN, USER4@EXAMPLE.COM, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

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

Системные поля Section Access

Уровни доступа назначаются пользователям в одной или нескольких таблицах безопасности, загруженных в части Section Access скрипта. Эти таблицы должны содержать как минимум два системных поля: ACCESSполе, которое определяет уровень доступа, и USERID или USER.EMAIL. Другие дополнительные системные поля можно добавить в зависимости от варианта использования. Ниже описан полный набор системных полей Section Access.

ACCESS

Определяет, какой уровень доступа должен иметь соответствующий пользователь.

Доступ к приложениям Qlik Sense может быть авторизован для указанных пользователей. В таблице безопасности пользователям могут быть назначены уровни доступа ADMIN или USER. Пользователь с правами ADMIN имеет доступ ко всем данным в приложении, если они не ограничены таблицей безопасности. Пользователь с правами USER имеет доступ только к данным, определенным в таблице безопасности. Если уровень доступа не назначен, пользователь не сможет открыть приложение.

USERID

Содержит строку, соответствующую имени пользователя Qlik Cloud. Программа Qlik Cloud получит сведения о входе в систему из субъекта IDP и сравнит ее со значением в данном поле. Альтернативный способ проверить удостоверение пользователя с помощью адреса электронной почты см. в разделе USER.EMAIL. В многооблачных средах субъект IDP можно сопоставить с внутренним удостоверением Windows. При использовании Qlik Account субъект нельзя сопоставить с внутренним удостоверением Windows. Субъект пользователя IDP можно просмотреть в разделе Пользователи в центре активности Администрирование.

Знак подстановки (*) интерпретируется как все пользователи согласно дальнейшим условиям, указанным в таблице безопасности. Например, в следующей таблице безопасности пользователи, которые относятся к администраторам клиента Qlik Sense, могут просматривать все перечисленные значения поля REDUCTION.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik SENSE TENANT ADMINS, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Примечание к информацииUSERID и NTNAME используют ту же самую информацию для проверки подлинности, таким образом, не нужно проверять их обоих в той же строке в таблице безопасности. Разница между этими двумя полями в том, что NTNAME также проверяет группы.

NTNAME

Примечание к информацииNTNAME — это поле из прежних версий QlikView, рекомендуется использовать USERID, если QlikView не использует ту же таблицу безопасности.

Поле, в котором должна содержаться строка, соответствующая версии NetBIOS имени пользователя или имени группы домена Windows NT. Если применяется другая система проверки подлинности, она должна содержать имя аутентифицируемого пользователя.

Программа Qlik Cloud получит сведения о входе в систему из утверждения subject поставщика удостоверений и сравнит ее со значением в данном поле.

USER.EMAIL

Содержит строку, соответствующую адресу электронной почты пользователя. Программа Qlik Cloud получит эту информацию от поставщика удостоверений и сравнит ее со значением в данном поле.

GROUP

Содержит строку, соответствующую группе в программе Qlik Cloud. Программа Qlik Cloud получит эту информацию из утверждения “groups” поставщика удостоверений и сравнит ее со значением в данном поле.

Примечание к информацииДанная функция недоступна в Qlik Sense Business, Аналитика Qlik Cloud Standard или при использовании поставщика удостоверений Qlik (IdP).

OMIT

Содержит имя поля, которое должно быть опущено для этого конкретного пользователя. Могут использоваться подстановочные знаки, и поле может быть пустым.

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

Управление доступом пользователя к приложению

Пользователь с идентификатором USERID AD_DOMAIN\C не сможет открыть приложение вообще, потому что этот идентификатор пользователя не указан в таблице безопасности.

Section Access в своей самой простой форме может использоваться для ограничения доступа определенных пользователей к приложению. Доступ пользователям к приложению запрещен посредством исключения. Другими словами, если определенный адрес электронной почты пользователя не указан в таблице безопасности, он не сможет получить доступ к приложению. Единственное исключение из этого правила — знак подстановки (*) присвоен полю USER.EMAIL в одной из строк таблицы безопасности. В этом случае знак подстановки означает, что все аутентифицированные пользователи могут получить доступ к приложению. Вот пример таблицы безопасности со списком идентификаторов пользователей:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

Пользователь с USER.EMAIL USER4@example.com не сможет открыть приложение вообще, потому что этот адрес электронной почты пользователя не указан в таблице безопасности.

Управление доступом пользователя к определенным данным в приложении

Динамическое сокращение данных ограничивает доступ к строкам и столбцам в таблицах данных в рамках приложений Qlik Sense приложений после того, как пользователь получил авторизацию на доступ к самому приложению.

Управление доступом к данным на уровне строк

Ограничьте доступ к данным на уровне строк, добавив столбец сокращения количества данных в таблицу безопасности в разделе доступа скрипта загрузки. Определенные записи (строки) можно скрыть от пользователей путем привязки данных Section Access к реальным данным. Выбор данных для отображения или исключения управляется с помощью одного или нескольких полей с общими именами в разделах скрипта Section Access и Section Application. После входа пользователя в систему программа Qlik Sense сопоставляет выборки в полях секции доступа с любыми полями приложения секции приложения с точно такими же именами (имена полей должны быть написаны в верхнем регистре). После создания выборок программа Qlik Sense постоянно скрывает все данные, исключенные этими выборками, от пользователя. Если знак подстановки (*) используется в качестве значения поля в столбце сокращения количества данных, он интерпретируется как разрешение доступа пользователю к записям, связанным со всеми выбранными полями сокращения в таблице безопасности.

Когда Qlik Sense сравнивает поле сокращения в Section Access с полями в модели данных, ожидается следующее поведение:

  • Если значение какого-либо поля в модели данных соответствует значению поля сокращения в Section Access, приложение откроется и в нем будут отображаться данные, связанные с этими совпадающими полями, для указанного пользователя. Остальные данные будут скрыты.

  • Если значение поля сокращения не соответствует ни одному из значений полей в модели данных, приложение не откроется для обычного ПОЛЬЗОВАТЕЛЯ. Но оно откроется без сокращений для пользователя с ролью АДМИНИСТРАТОР.

Не рекомендуется использовать несколько полей сокращения в Section Access, так как это позволит использовать другие комбинации доступа, отличные от предусмотренных.

Примечание к информации

Знак подстановки * в столбце сокращения количества данных относится только ко всем значениям в таблице безопасности. Если в разделе Section Application существуют значения, недоступные в столбце сокращения таблицы безопасности, они будут сокращены.

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

Пример: Сокращение количества данных на уровне строки на основе удостоверения пользователя

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 USER, USER4@EXAMPLE.COM, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

В этом примере поле REDUCTION (в верхнем регистре) теперь присутствует и в разделе Section Access, и в разделе Section Application (все значения полей также должны быть в верхнем регистре). Обычно два поля будут разделены и различны, но если используется Section Access, поля будут связаны, а количество записей, отображаемых для пользователя, сокращено.

Будет получен следующий результат:

  • Пользователь USER1@EXAMPLE.COM может просматривать все поля и только те записи, которые другие пользователи могут просматривать, когда REDUCTION = 1 или REDUCTION =2.
  • Пользователь USER2@EXAMPLE.COM может просматривать все поля, но только те записи, которые связаны с REDUCTION=1.
  • Пользователь USER3@EXAMPLE.COM может просматривать все поля, но только те записи, которые связаны с REDUCTION=2.
  • Пользователь USER4@EXAMPLE.COM может просматривать все поля и только те записи, которые другие пользователи могут просматривать, когда REDUCTION = 1 или REDUCTION =2.

Управление доступом к данным на уровне столбцов

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

Пример: Сокращение количества данных столбца на основе удостоверения пользователя

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Поле OMIT в разделе Section Access определяет поля, которые должны быть скрыты от пользователя.

Будет получен следующий результат:

  • Пользователь USER1@example.com может просматривать все поля и только те записи, которые другие пользователи могут просматривать в данном примере, когда для поля REDUCTION указано значение 1, 2 или 3.
  • Пользователь USER2@example.com может просматривать все поля, но только те записи, которые связаны с REDUCTION=1.
  • Пользователь USER3@example.com может просматривать все поля, кроме NUM, и только те записи, которые связаны с REDUCTION=2.
  • Пользователь USER4@example.com может просматривать все поля, кроме ALPHA, и только те записи, которые связаны с REDUCTION=3.
Примечание к информацииДля выполнения некоторых визуализаций предъявляются минимальные требования к данным. В результате может появиться предупреждение «Неполная визуализация», когда поле на уровне столбца отсутствует в виде данных пользователя.

Управление доступом к группам пользователей

Section Access предлагает возможность ограничить объем данных, видимых пользователям, с помощью принадлежности к группе. Для ограничения данных с помощью групп пользователей добавьте имя поля GROUP в таблицу безопасности в разделе Section Access и определите значения для поля GROUP.

Пример: Сокращение количества данных на основе групп пользователей

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, AD_DOMAIN\DEV, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Будет получен следующий результат:

  • Пользователям из группы ADMIN разрешено просматривать все поля и только те записи, которые другие пользователи могут просматривать в данном примере, когда для поля REDUCTION указано значение 1, 2 или 3.
  • Пользователи, принадлежащие к группе A, могут просматривать данные, связанные с REDUCTION=1, во всех полях.
  • Пользователи, принадлежащие к группе B, могут просматривать данные, связанные с REDUCTION=2, во всех полях, кроме поля NUM
  • Пользователи, принадлежащие к группе C, могут просматривать данные, связанные с REDUCTION=3, во всех полях, кроме поля ALPHA
  • Пользователи, принадлежащие к группе GROUP1, могут просматривать данные, связанные с REDUCTION=3, во всех полях
  • Пользователь AD_DOMAIN\DEV может просматривать все данные во всех полях.

Qlik Cloud сравнивает пользователя с UserID и разрешает вопрос с пользователем в отношении групп в таблице. Если пользователь принадлежит группе, к которой доступ разрешен, или пользователь совпадет с идентификатором, он получает доступ к приложению.

Перезагрузка данных в Qlik Cloud

Для перезагрузки приложения без сокращения количества данных в Qlik Cloud рекомендуется использовать системное поле USER.EMAIL в таблице безопасности. Значение для поля USER.EMAIL должно быть адресом электронной почты пользователей, которые могут изменять и загружать приложение. Это относится к приложениям как в общих, так и в управляемых пространствах. Пример:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, TEST@EXAMPLE.COM, * ];

В этом примере пользователь с адресом электронной почты test@example.com имеет права ADMIN и может перезагрузить приложение.

При использовании групп следующий пример будет работать одинаково как в Qlik Sense, так и в Qlik Cloud:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, DEVELOPERS, * ];

Также можно сопоставить USERID в таблице безопасности с subject claim поставщика удостоверений, как показано в следующем примере. Эта конфигурация предлагается для миграции с Qlik Sense на Qlik Cloud и для многооблачных сред. Для получения дополнительной информации о сопоставлении USERID с subject claim см. раздел Управление доступом пользователей в многооблачной среде

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

Управление доступом пользователей в многооблачной среде

Многооблачная среда Qlik Sense включает сочетание механизмов подлинности пользователя. Обычно в Qlik Sense Enterprise on Windows USERID в разделе Section Access таблицы безопасности проверяется прокси-службой. В Qlik Cloud роль проверки подлинности берет на себя поставщик удостоверений. Следовательно, Section Access, который настроен для локальной среды, такой как Qlik Sense Enterprise on Windows, не будет работать в облачной среде.

При использовании поставщика удостоверений OIDC или SAML (Qlik IdP или пользовательского поставщика удостоверений) с Qlik Cloud, subject claim применяется для идентификации пользователей при входе в систему. Section Access сравнивает значение поля USERID в таблице безопасности со значением subject claim. При настройке клиента убедитесь, что имя учетной записи SAM сопоставлено с subject claim поставщика удостоверений. Так, например, если имя учетной записи SAM — AD_DOMAIN\Dev, установите AD_DOMAIN\Dev для subject claim. Если нужно просмотреть значение subject claim в IdP, добавьте /api/v1/diagnose-claims к URL-адресу клиента в браузере, например: your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. В ответе JSON subject claim называется sub.

Если не удается использовать имя учетной записи SAM, есть альтернативный способ проверить подлинность пользователя. Так как в разных средах обычно используются одни и те же адреса электронной почты, можно использовать поле USER.EMAIL вместо USERID в таблице безопасности. Вот как может выглядеть таблица безопасности.

ACCESSUSERIDUSER.EMAILКомментарийCOUNTRY
USER

ABC\JOE

*Локальный доступСША
USER*

JOE.SMITH@EXAMPLE.COM

Доступ в облакеСША
USER

ABC\URSULA

*Локальный доступГермания
USER*

URSULA.SCHULTZ@EXAMPLE.COM

Доступ в облакеГермания
USER

ABC\STEFAN

*Локальный доступШвеция
USER*

STEFAN.SVENSSON@EXAMPLE.COM

Доступ в облакеШвеция

Скрипт авторизации:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\JOE, *, UNITED STATES USER, *, JOE.SMITH@EXAMPLE.COM, UNITED STATES USER, ABC\URSULA, *, GERMANY USER, *, URSULA.SCHULTZ@EXAMPLE.COM, GERMANY USER, ABC\STEFAN, *, SWEDEN USER, *, STEFAN.SVENSSON@EXAMPLE.COM, SWEDEN ];

Обратите внимание, что у каждого пользователя есть две записи: одна для локального и одна для облачного доступа. Знаки подстановки обеспечивают использование только соответствующих полей проверки подлинности. В этом примере COUNTRY используется в качестве поля для сокращения количества данных.

Поля авторизации QlikView

Для обратной совместимости Qlik Cloud распознает поля авторизации из QlikView. Хотя USERID интерпретируется по-разному в QlikView и Qlik Cloud, в Qlik Cloud он будет интерпретироваться так же, как и в Qlik Sense: он будет сопоставляться с именем аутентифицируемого пользователя.

PASSWORD, NTSID и NTDOMAINSID

Если одно из полей PASSWORD, NTSID и NTDOMAINSID используется и содержит соответствующее значение, доступ к документу будет запрещен. Если поле содержит подстановочный знак (*), доступ может быть предоставлен в зависимости от других полей в таблице авторизации.

SERIAL

Если поле SERIAL используется и содержит номер лицензии, то строка Section Access запретит доступ к документу. Если поле содержит подстановочный знак (*), доступ может быть предоставлен в зависимости от других полей в таблице авторизации.

Кроме того, в Qlik Cloud это поле может также использоваться для определения среды. Это означает, что если поле содержит строку ‘QLIKCLOUD’, доступ может быть предоставлен в зависимости от других полей в таблице авторизации.

Смешанные среды

Если планируется использовать одну и ту же таблицу безопасности в QlikView и Qlik Cloud, учтите следующее.

USERID имеет различные значения в QlikView и Qlik Cloud, и может вызвать проблемы безопасности, если используется. Используйте NTNAME вместо него или объедините его с SERIAL, как описано ниже.

GROUP и поля, начинающиеся с ‘USER.’, такие как 'USER.NAME' и 'USER.EMAIL', являются (или будут) полями авторизации в Qlik Cloud. При использовании этих полей в Section Access доступ может быть запрещен в Qlik Cloud.

PASSWORD, NTSID и NTDOMAINSID не могут использоваться в Qlik Cloud. Доступ будет запрещен, если не будет использоваться подстановочный знак.

SERIAL не может использоваться для проверки номера лицензии в Qlik Cloud. Однако, если это поле содержит строку ‘QLIKCLOUD’, доступ может быть предоставлен. Это означает, что можно иметь указанную ниже таблицу безопасности, где строка 1 предоставит доступ в QlikView (но не в Qlik Cloud), а строка 2 предоставит доступ в Qlik Cloud (но не в QlikView).

Таблица безопасности
СтрокаSERIALUSERIDКомментарий
14600 0123 4567 8901*Предоставляет доступ на исправление номера лицензии в QlikView.
2QLIKCLOUD

JOHN DOE

Предоставляет доступ на исправление пользователя в Qlik Cloud.

Скрипт авторизации:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, JOHN DOE, QLIKCLOUD ];

Использование Section Access и Insight Advisor Chat

В приложениях с поддержкой Section Access предусмотрен пользователь индекса для определения того, какой объем Insight Advisor Chat извлекает из приложения. В качестве пользователя индекса должен быть назначен пользователь с самым высоким уровнем доступа к приложению в скрипте Section Access. Однако данные, предоставляемые конечным пользователям, все равно регулируются ограничениями Section Access.

Видеоролик по использованию Section Access и Insight Advisor Chat:

Использование Section Access и Insight Advisor Chat

Примечание к предупреждению

Если в именах приложений, полей и основных элементов содержится конфиденциальная информация, они могут стать видимыми в результате обеспечения доступности приложений с Section Access для Insight Advisor Chat. Рекомендации приложений для запросов включают приложения в пространствах, доступных для пользователя. Они могут включать приложения, к которым у пользователей нет доступа через Section Access приложения. Однако при выборе таких приложений ничего не произойдет. При выборе Измерения или Меры для просмотра доступных элементов в приложении с использованием Section Access, пользователи могут увидеть объекты, к которым у них нет доступа. Однако при выборе этих элементов пользователи не увидят соответствующих данных.

По умолчанию пользователем индекса является владелец приложения. Пользователя индекса можно изменить в разделе Сведения.

  1. В Qlik Cloud перейдите к приложению.

  2. Щелкните значок Дополнительно на приложении и выберите Сведения.

  3. В поле Пользователь индекса выберите нужного пользователя.

  4. Щелкните Назад.

  5. Щелкните значок Дополнительно на приложении и выберите Перезагрузить.

Использование QVD с Section Access

QVD можно считывать как обычную загрузку или как оптимизированную загрузку. Оптимизированной является загрузка, когда при загрузке не выполняются преобразования данных и отсутствуют фильтры с предложением WHERE.

Оптимизированные загрузки не работают при использовании файлов QVD с Section Access. Если требуется использовать файл QVD для загрузки данных в Section Access, необходимо расширить файл QVD. Самый простой способ расширения файла QVD — изменить форматирование при загрузке данных.

В следующем примере файл QVD не расширяется, так как к данным не применяется форматирование.

Пример: Неработающий пример без форматирования данных (оптимизированная загрузка)

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd);

Вместо этого можно использовать функцию upper() для форматирования данных, в результате чего произойдет расширение файла QVD.

Пример: Рабочий пример с форматированием данных

section access; LOAD ACCESS, USERID, PASSWORD, upper([GROUP]) as [GROUP] FROM SAccess.qvd (qvd);

Также можно добавить предложение Where 1=1 в оператор LOAD.

Пример: Еще один рабочий пример с форматированием данных

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd) where 1=1;

Инструкции и советы по использованию Section Access

Вот некоторые важные факты и полезные советы, которые нужно знать о Section Access.

  • Все имена полей и значения полей, перечисленные в Section Access, всегда преобразуются в верхний регистр. В результате все поля, участвующие в сокращении количества данных, должны быть преобразованы в верхний регистр для приведения в соответствие с содержимым оператора Section Access, даже если они находятся вне оператора Section Access. Имя любого поля с буквами в нижнем регистре в базе данных можно преобразовать в верхний регистр с помощью функции Upper до чтения поля с помощью оператора LOAD или SELECT.

    Для получения дополнительной информации см. раздел Upper — функция скриптa и диаграммы.

  • Нельзя использовать имена системных полей Section Access, перечисленные в качестве имен полей, в вашей модели данных.
  • Перед тем как применить элементы управления Section Access, необходимо опубликовать приложения. Новые или измененные скрипты Section Access не применятся после перезагрузки приложения.
  • Снимок отображает данные в соответствии с правами доступа пользователя, создавшего снимок. Созданный снимок можно использовать в истории. Однако при возврате из истории в визуализацию для просмотра оперативных данных в приложении на пользователей распространяются ограничения, связанные с их правами доступа.
  • Не назначайте цвета значениям основного измерения, если используется Section Access или обрабатываются конфиденциальные данные, так как в этом случае значения можно определить по настройкам цвета.
  • Во избежание доступа к данным с ограниченным доступом после публикации приложения удалите все прикрепленные файлы с параметрами Section Access. Публикуемое приложение включает прикрепленные файлы. При копировании публикуемого приложения прикрепленные файлы включаются в копию. Однако, если к прикрепленным файлам данных были применены ограничения Section Access, при копировании прикрепленных файлов параметры Section Access не сохраняются, поэтому пользователи скопированного приложения могут видеть все данные прикрепленных файлов.
  • Знак подстановки (*) интерпретируется как все (перечисленные) значения поля в таблице. При использовании в одном из системных полей (USERID, GROUP) в таблице, загруженной в раздел Section Access скрипта, этот символ интерпретируется как все (также и неперечисленные) возможные значения этого поля.
  • Поля безопасности могут быть помещены в разные таблицы.
  • При загрузке данных из файла QVD использование функции Upper приведет к снижению скорости загрузки.

Помогла ли вам эта страница?

Если вы обнаружили какую-либо проблему на этой странице и с ее содержанием — будь то опечатка, пропущенный шаг или техническая ошибка, сообщите нам об этом, чтобы мы смогли ее исправить!