Gérer la sécurité, les erreurs, les avertissements et la journalisation

Cette section comprend les rubriques suivantes :

Sécurité

Une source de données peut fonctionner dans l'un des deux modes d'accès suivants:

  • En mode d'accès restreint, qui est le paramètre par défaut, une source de données ne diffuse que les requêtes provenant du même domaine que celui dans lequel se trouve la source de données. Le mode restreint empêche les attaques par falsification de requête intersites (XSRF). Il est donc plus sécurisé que le mode d'accès non restreint. Étant donné que la bibliothèque de sources de données fournit une interface uniquement pour renvoyer des données, et non pour modifier l'état ou les données côté serveur, seules les attaques XSRF qui tentent de voler des données sont possibles. Pour protéger votre source de données contre les tentatives de vol de données, le mode restreint doit être utilisé avec l'authentification basée sur les cookies. La méthode d'authentification des utilisateurs dépend de votre environnement et de votre implémentation.

  • En mode d'accès non restreint, une source de données diffuse toutes les requêtes, quelle que soit leur origine. Une source de données qui s'exécute en mode non restreint peut être protégée par une authentification basée sur les cookies, mais elle est vulnérable aux attaques XSRF. Utilisez le mode sans restriction si les visualisations sur des pages Web externes au domaine de la source de données doivent accéder à la source de données, ou si les données appartiennent au domaine public et n'ont donc pas besoin d'être protégées.

Une requête de visualisation peut spécifier un format de réponse JSON, CSV ou HTML. Le format de réponse détermine le format dans lequel une source de données renvoie une table de données. Étant donné que les formats CSV et HTML ne sont pas vulnérables aux attaques XSRF, ils sont accessibles à partir d'autres domaines, même en mode restreint.

Pour spécifier le mode sans restriction, remplacez isRestrictedAccessMode() comme suit:

  @Override
  protected boolean isRestrictedAccessMode() {
    return false;
  }

Par souci de simplicité, tous les exemples fournis avec la bibliothèque s'exécutent en mode d'accès non restreint.

Erreurs et avertissements

Lorsqu'il n'est pas possible, ou souhaitable, de renvoyer une table de données valide, la bibliothèque génère une exception DataSourceException. par exemple si l'utilisateur ne peut pas être authentifié. La bibliothèque génère ces exceptions lorsque des erreurs l'empêchent de créer une table de données. Vous pouvez générer des exceptions dans des situations propres à votre source de données. Si tel est le cas, créez vos propres types d'exceptions d'erreur en héritant de la classe DataSourceException. Vous pouvez également générer la classe DataSourceException directement.

La classe DataSourceException se trouve dans le package base et utilise les paramètres suivants:

  • ReasonType 
    Ce paramètre est obligatoire. Les types de motifs disponibles sont définis dans l'énumération ReasonType. Si aucun des types de motifs disponibles ne vous convient, vous pouvez utiliser Other ou Internal.
     
  • MessageToUser 
    Ce paramètre définit le texte du message d'erreur. Dans la plupart des cas, elles sont présentées à l'utilisateur sous la forme d'une info-bulle. Il est donc important de ne pas inclure d'informations techniques ou confidentielles.

Vous pouvez utiliser l'ensemble des fonctions d'assistance dans datasource.DataSourceHelper pour gérer les erreurs. Dans ce cas, appelez deux fonctions portant le même nom setErrorServletResponse pour accepter un DataSourceException et définir une erreur sur la réponse du servlet de données. L'une de ces fonctions accepte une requête de source de données, l'autre un HttpServlet request et est utilisée en cas d'échec de la création d'un DataSourceRequest. Un exemple d'implémentation est fourni dans la section Définir des fonctionnalités et le flux d'événements.

S'il n'est pas possible de renvoyer une table de données, la bibliothèque renvoie une erreur. S'il est possible de renvoyer un tableau de données, mais qu'il y a un problème à signaler, la bibliothèque affiche un avertissement avec le tableau de données. Par exemple, la bibliothèque crée un avertissement dans les situations suivantes:

  • si une visualisation interrogeant fournit un LIMIT qui entraîne des données tronquées.
  • si une visualisation requérant une requête requiert un modèle de mise en forme non valide dans une clause FORMAT.

Pour ajouter votre propre avertissement, créez une instance de base.Warning et ajoutez-la à votre table de données à l'aide de la méthode addWarning().

Journalisation

La bibliothèque utilise la journalisation Jakarta Commons. La journalisation Jakarta Commons peut être utilisée avec la plupart des systèmes de journalisation que vous avez peut-être déjà en place. Vous devrez peut-être écrire un adaptateur si votre système de journalisation n'est pas standard. Pour en savoir plus, consultez la page d'accueil de la journalisation des applications de Jakarta Commons.

Lorsqu'une exception est générée, des informations sont envoyées au journal. La manière dont vous accédez au journal dépend du système de journalisation que vous utilisez.