Ajout d’une logique d’application à un paquet d’application¶

Ajouter le code d’application de manière sécurisée¶

Toutes les procédures stockées et les UDFs au sein d’une Snowflake Native App s’exécutent comme l’application et ont accès à tous les objets de l”Snowflake Native App installée. Cela peut conduire à des attaques par injection SQL.

Lorsque vous développez des procédures et des fonctions à utiliser dans une Snowflake Native App, Snowflake recommande que toutes les commandes SQL nécessitant une entrée de la part des utilisateurs soient exécutées à l’aide de paramètres liés. Cela inclut les fournisseurs de données par le biais d’arguments de procédure.

Voir Création d’une procédure stockée pour plus d’informations.

À propos des droits de l’appelant et des droits du propriétaire¶

Toutes les procédures créées par le script d’installation ou exécutées au sein de la Snowflake Native App installée doivent être exécutées avec les droits du propriétaire (EXECUTE AS OWNER).

Cette restriction existe parce que si l”Snowflake Native App était exécutée avec les droits de l’appelant (EXECUTE AS CALLER) dans une procédure dont la Snowflake Native App n’est pas propriétaire, la procédure s’exécuterait en tant que Snowflake Native App elle-même et permettrait à un consommateur de créer du code pour voir ou modifier le contenu de l”Snowflake Native App et le contenu des données partagées.

Voir Understanding Caller’s Rights and Owner’s Rights Stored Procedures pour plus d’informations.

Limitations lors de l’appel de fonctions contextuelles à partir du script d’installation¶

Les fonctions de contexte fournissent des informations sur le contexte dans lequel une instruction est exécutée. Dans le contexte du Snowflake Native App Framework, certaines fonctions contextuelles ne sont pas disponibles. Les fonctions contextuelles qui ne sont pas disponibles sont soit bloquées et renvoient une erreur, soit renvoient toujours une valeur nulle.

En général, vous devez faire preuve de prudence lorsque vous utilisez des fonctions contextuelles dans des politiques appliquées à du contenu de données partagées au sein d’une Snowflake Native App. Certaines fonctions, par exemple CURRENT_IP_ADDRESS, se comportent différemment dans le contexte d’une Snowflake Native App.

Notez que lorsque vous utilisez des fonctions contextuelles qui dépendent de l’espace de noms au sein de l’organisation cliente, il peut y avoir des conflits avec des fonctions dans d’autres espaces de noms. Par exemple, une politique d’accès aux lignes utilisant CURRENT_USER doit tenir compte du fait qu’un même nom d’utilisateur peut exister dans plusieurs comptes.

Le tableau suivant répertorie les fonctions contextuelles qui ne sont pas prises en charge par le Snowflake Native App Framework :

Référencer des fichiers de code externes¶

Il existe deux types de fichiers de code que vous pouvez inclure dans un paquet d’application :

• Fichiers référencés : comprennent les fichiers binaires, les bibliothèques et d’autres fichiers de code. Ces fichiers sont spécifiques à une version définie dans un paquet d’application. Ces fichiers doivent se trouver dans le répertoire racine de la zone de préparation lors de la création d’un paquet d’application.

  Les fichiers référencés sont différents des fonctions définies par l’utilisateur et des procédures stockées, car ils ne sont pas définis dans le script d’installation d’un paquet d’application. Ces fichiers sont référencés par les instructions d’importation dans les procédures stockées et les UDFs qui dont définies dans le script d’installation.

• Fichiers de ressources : comprennent les données semi-structurées, les données structurées et les binaires, comme un modèle de machine learning. Ces fichiers doivent être chargés dans une zone de préparation nommée accessible au paquet d’application.

Une procédure stockée, une fonction définie par l’utilisateur ou une fonction externe qui fait référence à ces types de fichiers de code doit être créée dans un schéma versionné dans le script d’installation. Lorsque vous créez des procédures stockées ou des fonctions dans un schéma versionné, vous devez faire référence à un fichier de code relatif au répertoire racine de la zone de préparation nommée.

Par exemple, si le répertoire racine de votre zone de préparation est /app_files/dev, ce répertoire contiendra les fichiers et répertoires suivants :

• Un fichier manifest.yml.

• Un répertoire contenant le script d’installation, par exemple scripts/setup_version.sql.

• Fichiers référencés qui sont importés lors de la création d’une procédure stockée, d’une UDF ou d’une fonction externe dans le script d’installation, par exemple :

  • libraries/jars/lookup.jar

  • libraries/jars/log4j.jar

  • libraries/python/evaluate.py

Dans ce scénario, la structure du répertoire serait la suivante :

@DEV_DB.DEV_SCHEMA.DEV_STAGE/V1:
└── app_files/
    └── dev
        ├── manifest.yml
        └── scripts/
            ├── setup_script.sql
            └── libraries/
                └── jars/
                    ├── lookup.jar
                    └── log4j.jar
            └── python
                └── evaluation.py

Pour accéder aux fichiers JAR dans cette structure de répertoire, une procédure stockée définie dans le script d’installation fait référence à ces fichiers, comme le montre l’exemple suivant :

CREATE PROCEDURE PROGRAMS.LOOKUP(...)
 RETURNS STRING
 LANGUAGE JAVA
 PACKAGES = ('com.snowflake:snowpark:latest')
 IMPORTS = ('/scripts/libraries/jar/lookup.jar',
            '/scripts/libraries/jar/log4j.jar')
 HANDLER = 'com.acme.programs.Lookup';

Dans cet exemple, l’instruction IMPORTS a un chemin relatif vers le répertoire racine utilisé pour créer la version, par exemple, l’emplacement du fichier manifest.yml.

Inclure du code Java et Scala dans un paquet d’application¶

Le Snowflake Native App Framework permet d’utiliser Java et Scala dans des procédures stockées et dans des fichiers de code externes.

CREATE OR ALTER VERSIONED SCHEMA app_code;
CREATE STAGE app_code.app_jars;

CREATE FUNCTION app_code.add(x INT, y INT)
 RETURNS INTEGER
 LANGUAGE JAVA
 HANDLER = 'TestAddFunc.add'
 TARGET_PATH = '@app_code.app_jars/TestAddFunc.jar'
 AS
 $$
   class TestAddFunc {
       public static int add(int x, int y) {
           Return x + y;
       }
   }
 $$;

@DEV_DB.DEV_SCHEMA.DEV_STAGE/V1:
└── V1/
 ├── manifest.yml
 ├── setup_script.sql
 └── JARs/
     ├── Java/
     │   └── TestAddFunc.jar
     └── Scala/
         └── TestMulFunc.jar

CREATE FUNCTION app_code.add(x INTEGER, y INTEGER)
  RETURNS INTEGER
  LANGUAGE JAVA
  HANDLER = 'TestAddFunc.add'
  IMPORTS = ('/JARs/Java/TestAddFunc.jar');

Ajouter du code Python à un paquet d’application¶

Le Snowflake Native App Framework prend en charge l’utilisation de Python dans les procédures stockées et dans les fichiers de code externes.

CREATE FUNCTION app_code.py_echo_func(str STRING)
RETURNS STRING
LANGUAGE PYTHON
HANDLER = 'echo'
AS
$$
  def echo(str):
    return "ECHO: " + str
$$;

CREATE FUNCTION PY_PROCESS_DATA_FUNC()
  RETURNS STRING
  LANGUAGE PYTHON
  HANDLER = 'TestPythonFunc.process'
  IMPORTS = ('/python_modules/TestPythonFunc.py',
    '/python_modules/data.csv')

Traiter les erreurs JavaScript¶

Lorsque vous utilisez JavaScript au sein d’un paquet d’application, Snowflake vous recommande de détecter et de gérer les erreurs. Dans le cas contraire, le message d’erreur et le traçage de la pile renvoyée par l’erreur sont visibles par le consommateur. Pour garantir la confidentialité du contenu des données et de la logique d’application, utilisez des blocs try/catch dans les situations où des objets ou des données sensibles sont accessibles.

L’exemple suivant montre une procédure stockée JavaScript qui détecte une erreur et renvoie un message :

CREATE OR REPLACE PROCEDURE APP_SCHEMA.ERROR_CATCH()
  RETURNS STRING
  LANGUAGE JAVASCRIPT
  EXECUTE AS OWNER
  AS $$
     try {
      let x = y.length;
     }
     catch(err){
        return "There is an error.";
     }
     return "Done";
  $$;

Cet exemple crée une procédure stockée JavaScript qui contient une bloc try/catch. Si la procédure stockée rencontre une erreur lors de l’exécution de l’instruction dans le bloc try elle renvoie le message « Il y a une erreur » qui est visible par le consommateur.

Sans le bloc try/catch, la procédure stockée renverrait le message d’erreur d’origine et le traçage complet de la pile, qui serait visible pour le consommateur.