Przeskocz do zawartości głównej

Zarządzanie bezpieczeństwem przy użyciu instrukcji Section Access

Section Access służy do kontrolowania bezpieczeństwa aplikacji. Zasadniczo jest to część skryptu ładowania danych, w której dodaje się tabelę zabezpieczeń, aby określić, co kto może zobaczyć. Qlik Sense SaaS wykorzystuje te informacje do zredukowania danych do odpowiedniego zakresu, gdy użytkownik otwiera aplikację. Oznacza to, że niektóre dane w aplikacji są ukrywane przed użytkownikiem na podstawie jego tożsamości. Instrukcja Section Access jest ściśle zintegrowana z danymi w aplikacji i polega na nich w kwestii kontroli dostępu. Ta forma dynamicznej redukcji danych może być stosowana do wierszy tabeli, kolumn lub ich kombinacji. Aby uzyskać więcej informacji, odwiedź stronę Zaufanie i bezpieczeństwo w Qlik.

Sekcje w skrypcie ładowania.

Zarządzanie kontrolą dostępu do danych odbywa się z wykorzystaniem jednej lub większej liczby tabel zabezpieczeń, które są ładowane w taki sam sposób jak zwykłe dane. Dzięki temu można przechowywać te tabele w standardowej bazie danych lub w arkuszu kalkulacyjnym. Instrukcje skryptu używane do zarządzania tabelami zabezpieczeń są podane w sekcji autoryzacji, inicjowanej w skrypcie instrukcją Section Access.

Jeśli skrypt zawiera definicję sekcji autoryzacji, część skryptu ładująca dane aplikacji musi znajdować się w odrębnej sekcji, zainicjowanej instrukcją Section Application.

Przykład:  

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, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Należy pamiętać, że po wprowadzeniu zmian w skrypcie ładowania należy zawsze załadować dane, aby zmiany zostały zastosowane.

Pola systemowe w instrukcji Section Access

Poziomy dostępu są przypisywane użytkownikom w jednej lub kilku tabelach zabezpieczeń ładowanych w części Section Access skryptu. Tabele te muszą zawierać co najmniej dwa pola systemowe: ACCESS, czyli pole określające poziom dostępu i USERID lub USER.EMAIL . Inne opcjonalne pola systemowe można dodać w zależności od przypadku. Poniżej opisano pełny zestaw pól systemowych instrukcji Section Access.

ACCESS

Określa poziom dostępu danego użytkownika.

Uprawienia dostępu do aplikacji w Qlik Sense można przyznawać określonym użytkownikom. W tabeli zabezpieczeń każdy użytkownik może mieć jeden z dwóch poziomów dostępu: ADMIN lub USER. Użytkownik z uprawnieniami ADMIN ma dostęp do wszystkich danych w aplikacji, chyba że ogranicza to tabela zabezpieczeń. Użytkownik z uprawnieniami USER ma dostęp do danych jedynie w zakresie zdefiniowanym w tabeli zabezpieczeń. Jeśli użytkownikowi nie zostanie przypisany żaden poprawny poziom dostępu, nie będzie on mógł otworzyć danej aplikacji.

USERID

Zawiera ciąg znaków odpowiadający nazwie użytkownika Qlik Sense SaaS. Qlik Sense SaaS pobierze dane logowania z podmiotu IdP i porówna je z wartościami w tym polu. Alternatywny sposób weryfikowania tożsamości użytkownika przy użyciu adresu e-mail opisano w temacie USER.EMAIL. Podmiot IdP może zostać zmapowany względem wewnętrznej tożsamości systemu Windows na rzecz środowiska do obsługi wielu chmur. Podczas korzystania z Qlik Account podmiot nie może zostać zmapowany względem wewnętrznej tożsamości systemu Windows. Użytkownik podmiotu IdP może zostać wyświetlony w sekcji Użytkownicy Konsola zarządzania.

Znak wieloznaczny (*) jest interpretowany jako wszyscy użytkownicy, z zastrzeżeniem dalszych warunków określonych w tabeli zabezpieczeń. Na przykład w poniższej tabeli zabezpieczeń użytkownicy należący do grupy Qlik Sense Tenant Admins mogą zobaczyć wszystkie wymienione wartości REDUCTION.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];
Informacja USERID oraz NTNAME używają tych samych danych uwierzytelniających, zatem sprawdzenie obu elementów w tym samym wierszu tabeli zabezpieczeń nie jest konieczne. Różnica między tymi dwoma polami polega na tym, że NTNAME sprawdza także grupy.

NTNAME

InformacjaNTNAME jest starszą wersją pola QlikView i zaleca się używanie USERID, jeśli QlikView nie używa tej samej tabeli zabezpieczeń.

Pole, które powinno zawierać ciąg znaków odpowiadający nazwie użytkownika lub grupy wersji NetBIOS domeny systemu Windows NT. Jeśli wykorzystywany jest inny system uwierzytelniania, powinien zawierać nazwę zweryfikowanego użytkownika.

Qlik Sense SaaS pobierze dane logowania z oświadczenia subject dostawcy tożsamości i porówna je z wartościami w tym polu.

USER.EMAIL

Zawiera ciąg znaków odpowiadający adresowi e-mail użytkownika. Program Qlik Sense SaaS pobierze te dane od dostawcy tożsamości i porówna je z wartością w tym polu.

GROUP

Zawiera ciąg znaków odpowiadający grupie w programie Qlik Sense SaaS. Qlik Sense SaaS pobierze dane z oświadczenia “groups” dostawcy tożsamości i porówna je z wartościami w tym polu.

InformacjaGrupy użytkowników nie są obsługiwane w Qlik Sense Business ani podczas używania dostawcy tożsamości Qlik.

OMIT

Zawiera nazwę pola, które ma zostać pominięte w odniesieniu do danego użytkownika. Pole może zawierać symbole wieloznaczne lub być puste.

InformacjaZalecane jest, aby nie stosować OMIT w przypadku pól kluczowych. Pola klucza, które są pomijane, są widoczne w przeglądarce modelu danych, ale ich zawartość jest niedostępna, co może być mylące dla użytkownika. Ponadto zastosowanie pola OMIT względem pól używanych w wizualizacji może spowodować, że wizualizacja będzie niekompletna dla użytkowników, którzy nie mają dostępu do pól pominiętych.

Zarządzanie dostępem użytkownika do aplikacji

Użytkownik z identyfikatorem USERID AD_DOMAIN\C nie mógłby w ogóle otworzyć aplikacji, ponieważ ten identyfikator użytkownika nie jest wymieniony w tabeli zabezpieczeń.

Do ograniczenia dostępu do aplikacji określonym użytkownikom można użyć instrukcji Section Access w jej najprostszej formie. Użytkownicy nie mają dostępu do aplikacji przez wykluczenie. Innymi słowy, jeśli określony adres e-mail użytkownika nie zostanie wymieniony w tabeli zabezpieczeń, dany użytkownik nie będzie mógł uzyskać dostępu do aplikacji. Jedynym wyjątkiem od tej reguły jest sytuacja, w której symbol wieloznaczny (*) zostanie przypisany do pola USER.EMAIL w jednym z wierszy tabeli zabezpieczeń. W tym przypadku symbol wieloznaczny oznacza, że wszyscy uwierzytelnieni użytkownicy mają dostęp do aplikacji. Oto przykład tabeli zabezpieczeń z listą identyfikatorów użytkowników:

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

Użytkownik z adresem USER.EMAIL USER4@example.com nie mógłby w ogóle otworzyć aplikacji, ponieważ ten adres e-mail użytkownika nie jest wymieniony w tabeli zabezpieczeń.

Zarządzanie dostępem użytkownika do określonych danych w aplikacji

Dynamiczna redukcja danych ogranicza dostęp do wierszy i kolumn w tabelach danych w aplikacjach Qlik Sense po autoryzacji użytkownika w celu uzyskania dostępu do samej aplikacji.

Zarządzanie dostępem do danych na poziomie wiersza

Dostęp do danych na poziomie wiersza można ograniczyć, dodając kolumnę redukcji danych do tabeli zabezpieczeń w sekcji dostępu skryptu ładowania. Określone rekordy (wiersze) można ukrywać przed użytkownikami przez powiązanie danych instrukcji Section Access z rzeczywistymi danymi. Kontrolowanie zakresu danych wyświetlanych lub wykluczanych polega na używaniu pól redukcji o takich samych nazwach w częściach Section Access i Section Application skryptu. Po zalogowaniu użytkownika program Qlik Sense dopasuje wybory w polach redukcji w sekcji dostępu do pól o identycznych nazwach w sekcji aplikacji (nazwy pól muszą być zapisane wielkimi literami). Po dokonaniu wyborów program Qlik Sense trwale ukryje przed użytkownikiem wszystkie dane wykluczone na podstawie tych wyborów. Jeśli jako wartość pola w kolumnie redukcji danych jest używany symbol wieloznaczny (*), jest on interpretowany jako umożliwiający użytkownikowi dostęp do rekordów powiązanych ze wszystkimi wybranymi polami redukcji w tabeli zabezpieczeń.

Informacja

Znak wieloznaczny * w kolumnie redukcji danych odnosi się tylko do wszystkich wartości w tabeli zabezpieczeń. Jeśli w części Section Application znajdują się wartości, które są niedostępne w kolumnie redukcji tabeli zabezpieczeń, zostaną one zredukowane.

InformacjaWszystkie nazwy pól używane w opisanej powyżej procedurze przenoszenia oraz wszystkie wartości tych pól muszą być zapisane wielkimi literami, ponieważ w sekcji dostępu wszystkie nazwy i wartości pól są domyślnie zamieniane na wielkie litery.

Przykład: Redukcja danych na podstawie tożsamości użytkownika

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;

W tym przykładzie pole REDUCTION (nazwa zapisana wielkimi literami) istnieje teraz w części zarówno Section Access, jak i Section Application (wszystkie wartości pola również są zapisane wielkimi literami). W zwykłej sytuacji te dwa pola byłyby różne i niepowiązane, ale przez zastosowanie dostępu do sekcji zostaną one powiązane i wykorzystane do zredukowania liczby rekordów wyświetlanych użytkownikowi.

Wynik będzie następujący:

  • Użytkownik USER1@example.com widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.
  • Użytkownik USER2@example.com widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
  • Użytkownik USER3@example.com widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=2.
  • Użytkownik USER4@example.com widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.

Zarządzanie dostępem do danych na poziomie kolumn

Dostęp do danych na poziomie kolumny można ograniczyć, dodając pole systemowe OMIT do tabeli zabezpieczeń w skrypcie Section Access. Poniższy przykład opiera się na poprzednim przykładzie, w którym stosowana jest już redukcja danych wiersza.

Przykład: Redukcja danych kolumny na podstawie identyfikatora użytkownika

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;

Pole OMIT w dostępie do sekcji definiuje pola, które mają być ukryte przed użytkownikiem.

Wynik będzie następujący:

  • Użytkownik USER1@example.com widzi wszystkie pola oraz tylko te rekordy w tym przykładzie, które mogą wyświetlać inni użytkownicy, gdy REDUCTION to 1, 2 lub 3.
  • Użytkownik USER2@example.com widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
  • Użytkownik USER3@example.com widzi wszystkie pola oprócz NUM i jedynie rekordy powiązane z wartością REDUCTION=2.
  • Użytkownik USER4@example.com widzi wszystkie pola oprócz ALPHA i jedynie rekordy powiązane z wartością REDUCTION=3.
InformacjaNiektóre wizualizacje mają minimalne wymagania dotyczące danych, które należy spełnić, aby były renderowane. W rezultacie może zostać wyświetlony komunikat „Niekompletna wizualizacja”, gdy pole na poziomie kolumny zostanie pominięte w widoku danych użytkownika.

Zarządzanie dostępem do grup użytkowników

Instrukcja Section Access umożliwia ograniczenie zakresu danych widocznych dla użytkowników na podstawie członkostwa w grupie. Aby ograniczyć dane przy użyciu grup użytkowników, dodaj nazwę pola GROUP do tabeli zabezpieczeń w sekcji dostępu i zdefiniuj wartości dla pola GROUP.

Przykład: Redukcja danych na podstawie grup użytkownika

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;

Wynik będzie następujący:

  • Użytkownicy należący do grupy ADMIN widzą wszystkie dane i pola.
  • Użytkownicy należący do grupy A widzą dane powiązane z wartością REDUCTION=1 we wszystkich polach.
  • Użytkownicy należący do grupy B widzą dane powiązane z wartością REDUCTION=2, ale nie dane z pola NUM
  • Użytkownicy należący do grupy C widzą dane powiązane z wartością REDUCTION=3, ale nie dane z pola ALPHA
  • Użytkownicy należący do grupy GROUP1 widzą dane powiązane z wartością REDUCTION=3 we wszystkich polach
  • Użytkownik AD_DOMAIN\DEV widzi wszystkie dane we wszystkich polach.

Qlik Sense SaaS porówna dane użytkownika dostarczone przez serwer proxy z identyfikatorem użytkownika (UserID) i rozpozna użytkownika względem grup w tabeli. Jeśli użytkownik jest zgodny lub należy do grupy z uprawnieniami dostępu, może otrzymać dostęp do aplikacji.

Ładowanie danych w Qlik Sense SaaS

Aby załadować aplikację bez redukcji danych w Qlik Sense SaaS, zaleca się użycie pola systemowego USER.EMAIL w tabeli zabezpieczeń. Wartością pola USER.EMAIL powinien być adres e-mail użytkowników, którzy mogą edytować i ładować aplikację. Dotyczy to aplikacji w przestrzeniach zarówno udostępnionych, jak i zarządzanych. Na przykład:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, test@example.com, * ];

W tym przykładzie użytkownik z adresem e-mail test@example.com ma uprawnienia ADMIN i może załadować aplikację.

Jeśli korzystasz z grup, poniższy przykład zadziała w Qlik Sense i Qlik Sense SaaS:

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

Można także zamapować USERID w tabeli zabezpieczeń do subject claim dostawcy tożsamości, jak pokazano w poniższym przykładzie. Ta konfiguracja jest zalecana do migracji z Qlik Sense do Qlik Sense SaaS oraz do środowisk wielochmurowych. Aby uzyskać więcej informacji na temat mapowania USERID do subject claim, zobacz temat Zarządzanie dostępem użytkowników w środowisku wielochmurowym

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

Zarządzanie dostępem użytkowników w środowisku wielochmurowym

Środowisko wielochmurowe Qlik Sense obejmuje różne mechanizmy uwierzytelniania użytkowników. W przypadku Qlik Sense Enterprise on Windows identyfikator USERID jest zwykle weryfikowany w tabeli zabezpieczeń przez usługę proxy. W Qlik Sense SaaS tę rolę uwierzytelniania przyjmuje dostawca tożsamości. W związku z tym instrukcja Section Access skonfigurowana dla środowiska lokalnego, takiego jak Qlik Sense Enterprise on Windows, nie będzie działać w środowisku chmurowym.

W przypadku korzystania z dostawcy tożsamości OIDC (Qlik IdP lub niestandardowego dostawcy tożsamości) z Qlik Sense SaaS subject claim jest używane do identyfikacji użytkowników podczas logowania. Jeżeli stosowana jest instrukcja Section Access, wartość pola USERID w tabeli zabezpieczeń jest porównywana z wartością subject claim. Podczas konfiguracji dzierżawy dopilnuj, by nazwa konta SAM została zamapowana do subject claim Twojego dostawcy tożsamości. Na przykład, jeśli nazwa Twojego konta SAM to AD_DOMAIN\Dev, ustaw subject claim na AD_DOMAIN\Dev. Aby zobaczyć wartość subject claim dostawcy tożsamości, dołącz /api/v1/diagnose-claims do adresu URL dzierżawy w przeglądarce, na przykład your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. W odpowiedzi JSON subject claim nazywa się sub.

Jeśli nie możesz użyć nazwy konta SAM, istnieje inny sposób uwierzytelnienia użytkownika. Ponieważ adresy e-mail zwykle pozostają takie same w różnych środowiskach, możesz użyć w tabeli zabezpieczeń pola USER.EMAIL zamiast USERID. Oto przykład tego, jak mogłaby wyglądać tabela zabezpieczeń:

ACCESS USERID USER.EMAIL Comment COUNTRY
USER ABC\Joe * Access-on-prem United States
USER * joe.smith@example.com Access-in-cloud United States
USER ABC\Ursula * Access-on-prem Germany
USER * ursula.schultz@example.com Access-in-cloud Germany
USER ABC\Stefan * Access-on-prem Sweden
USER * stefan.svensson@example.com Access-in-cloud Sweden

Skrypt autoryzacji:

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 ];

Pamiętaj, że każdy użytkownik ma dwa rekordy: Jeden do dostępu lokalnego, a drugi do dostępu w chmurze. Symbole wieloznaczne zapewniają używanie tylko odpowiednich pól uwierzytelniających. W tym przykładzie pole COUNTRY jest używane jako pole redukcji danych.

Pola autoryzacji programu QlikView

Qlik Sense SaaS rozpoznaje pola autoryzacji z programu QlikView na rzecz zachowania zgodności z poprzednimi wersjami. Chociaż USERID jest różnie interpretowany w QlikView i Qlik Sense SaaS, w Qlik Sense SaaS będzie interpretowany tak samo jak w Qlik Sense: zostanie zestawiony z nazwą zweryfikowanego użytkownika.

PASSWORD, NTSID oraz NTDOMAINSID

Jeśli jedno z pól PASSWORD, NTSID lub NTDOMAINSID jest używane i zawiera odpowiednią wartość, dostęp do dokumentu nie jest przyznany. Jeśli pole zawiera symbol wieloznaczny (*), dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

SERYJNE

Jeśli pole SERIAL jest używane i zawiera numer licencji, wiersz Dostęp do sekcji odmówi dostępu do dokumentu. Jeśli pole zawiera symbol wieloznaczny (*), dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

Dodatkowo w Qlik Sense SaaS to pole może zostać użyte także w celu definiowania środowiska. Oznacza to, że jeśli pole zawiera ciąg znaków „QLIKCLOUD”, dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

Środowiska mieszane

Jeśli planujesz użycie tej samej tabeli zabezpieczeń zarówno w QlikView, jak i Qlik Sense SaaS, należy pamiętać, że:

USERID ma różne znaczenia w QlikView i Qlik Sense SaaS, a chmura, jeśli jest w użyciu, powoduje problemy związane z zabezpieczeniami. W zamian użyj NTNAME lub połącz z SERIAL, jak opisano poniżej.

GROUP oraz pola rozpoczynające się od „USER.”, np. „USER.NAME” lub „USER.EMAIL” są (lub będą) polami autoryzacji w Qlik Sense SaaS. Jeśli używasz tych pól w części Dostęp do sekcji, dostęp może nie zostać przyznany w Qlik Sense SaaS.

PASSWORD, NTSID i NTDOMAINSID nie mogą być użyte w Qlik Sense SaaS. Dostęp nie zostanie przyznany dopóki używany jest symbol wieloznaczny.

SERIAL nie może być użyty w celu sprawdzenia numeru licencji w Qlik Sense SaaS. Jeśli jednak to pole zawiera ciąg znaków „QLIKCLOUD”, dostęp może zostać przyznany. To oznacza, że jest możliwe uzyskanie tabeli zabezpieczeń podobnej do następującej, gdzie linia 1 przyzna dostęp do QlikView (ale nie do Qlik Sense SaaS), a linia 2 przyzna dostęp do Qlik Sense SaaS (ale nie do QlikView).

Tabela zabezpieczeń
Linia SERIAL USERID Comment
1 4600 0123 4567 8901 * Przyznaje dostęp do poprawnego numeru licencji w QlikView.
2 QLIKCLOUD John Doe Przyznaje dostęp do poprawnego użytkownika w Qlik Sense SaaS.

Skrypt autoryzacji:

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

Używanie Section Access i Insight Advisor Chat

Aplikacje korzystające z instrukcji Section Access używają użytkownika indeksu do określenia ilości informacji pobieranych przez Insight Advisor Chat z aplikacji. Użytkownik indeksu powinien być użytkownikiem z najwyższym poziomem dostępu do aplikacji w skrypcie Section Access. Dane dostarczane użytkownikom końcowym są jednak nadal kontrolowane przez ograniczenia instrukcji Section Access.

Ostrzeżenie

Jeśli masz poufne informacje w nazwach aplikacji, pól lub elementów głównych, mogą one zostać ujawnione przez udostępnienie aplikacji używających instrukcji Section Access dla funkcji Insight Advisor Chat. Sugestie aplikacji dotyczące zapytań obejmują aplikacje ze strumieni, do których użytkownicy mają dostęp. Mogą to być aplikacje, do których użytkownicy nie mają dostępu w instrukcji Section Access aplikacji. Jednak wybranie tych aplikacji nie da żadnych efektów. Po kliknięciu Wymiary lub Miary w celu wyświetlenia dostępnych elementów z aplikacji używającej instrukcji Section Access użytkownicy mogą zobaczyć elementy, do których nie mają dostępu. Kliknięcie tych elementów nie spowoduje jednak udostępnienia użytkownikom żadnych danych.

Domyślnie właścicielem aplikacji jest użytkownik indeksu. Użytkownika indeksu można zmienić w Szczegółach.

  1. W Qlik Cloud przejdź do aplikacji.

  2. Kliknij Więcej w aplikacji i wybierz opcję Szczegóły.

  3. W polu Użytkownik indeksu wybierz użytkownika indeksu.

  4. Kliknij Wstecz.

  5. Kliknij Więcej w aplikacji i wybierz opcję Przeładuj.

Wytyczne i wskazówki dotyczące korzystania z instrukcji Section Access

Oto kilka ważnych faktów i przydatnych wskazówek dotyczących instrukcji Section Access.

  • Wszystkie pola wymienione w instrukcjach LOAD lub SELECT w sekcji dostępu muszą być zapisane wielkimi literami. Zmień zapis wszelkich nazw pól zawierających w bazie danych małe litery na zapis wielkimi literami przy użyciu funkcji Upper, zanim pole zostanie odczytane przez instrukcję LOAD lub SELECT.

    Więcej informacji zawiera temat Upper — funkcja skryptu i funkcja wykresu.

  • Wymienione tutaj nazwy pól systemowych Section Access nie mogą być używane jako nazwy pól w modelu danych.
  • Aplikacje muszą zostać opublikowane przed zastosowaniem środków kontroli z części Section Access. Załadowanie aplikacji nie spowoduje zastosowania nowych ani zmienionych skryptów Section Access.
  • Migawka przedstawia dane zgodnie z uprawnieniami dostępu użytkownika, który ją rejestruje, i może być udostępniana w narracji. Użytkownicy wracający do wizualizacji z narracji w celu wyświetlenia danych na żywo w aplikacji są jednak ograniczeni własnymi uprawnieniami dostępu.
  • Do wartości wymiaru głównego nie należy przypisywać kolorów, jeśli korzysta się z dostępu do sekcji albo z danych poufnych, ponieważ wartości mogą zostać ujawnione przez konfigurację kolorów.
  • Aby uniknąć ujawnienia zastrzeżonych danych, przed opublikowaniem aplikacji należy usunąć wszystkie dołączone pliki, względem których obowiązują ustawienia dostępu do sekcji. Dołączone pliki są zawarte w momencie publikowania aplikacji. Jeśli publikowana aplikacja zostanie skopiowana, dołączone pliki zostaną dodane do kopii. Jeśli jednak względem dołączonych plików danych zastosowano ograniczenia dostępu do sekcji, wówczas ustawienia dostępu do sekcji nie zostaną zachowane w przypadku skopiowania plików, dzięki czemu użytkownicy skopiowanej aplikacji będą widzieć wszystkie dane w dołączonych plikach.
  • Symbol wieloznaczny (*) jest interpretowany jako wszystkie (wymienione) wartości tego pola w tabeli. Jego użycie w jednym z pól systemowych (USERID, GROUP) w tabeli załadowanej w sekcji dostępu skryptu jest interpretowane jako wszystkie możliwe (nie tylko wymienione) wartości tego pola.
  • Pola zabezpieczeń można umieścić w różnych tabelach.
  • W przypadku ładowania danych z pliku QVD funkcja Upper powoduje spowolnienie procesu ładowania.