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 mode 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 des requêtes intersites (XSRF) et 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 permettant de renvoyer uniquement des données, et non de modifier l'état ou les données côté serveur, seules les attaques XSRF visant à 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é conjointement avec l'authentification basée sur les cookies. La méthode d'authentification des utilisateurs dépend de votre environnement et de votre mise en œuvre.

  • En mode d'accès illimité, une source de données traite toutes les requêtes, quelle que soit leur origine. Une source de données exécutée en mode sans restriction peut être protégée par une authentification basée sur les cookies. Notez toutefois que la source de données sera vulnérable aux attaques XSRF. Utilisez le mode sans restriction si des 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 ne doivent donc pas ê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 illimité.

Erreurs et avertissements

Lorsqu'il est impossible ou souhaitable de renvoyer une table de données valide, la bibliothèque renvoie une 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 vouloir générer des exceptions dans des situations spécifiques à votre source de données. Si tel est le cas, créez vos propres types d'exceptions d'erreurs en héritant de la classe DataSourceException. Vous pouvez également lancer directement la classe DataSourceException.

La classe DataSourceException se trouve dans le package base. Elle prend 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 convient, vous pouvez utiliser Other ou Internal.
     
  • MessageToUser
    Ce paramètre définit le texte du message d'erreur. Dans la plupart des cas, elle est présentée à 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 de fonctions d'aide dans datasource.DataSourceHelper pour gérer les erreurs. Dans ce cas, appelez deux fonctions portant le même nom setErrorServletResponse pour prendre une DataSourceException et définir une erreur sur la réponse du servlet de données. L'une de ces fonctions prend une requête de source de données, l'autre une fonction HttpServlet request et est utilisée en cas d'échec de la création d'une DataSourceRequest. Vous trouverez un exemple de mise en œuvre à la page Définir les fonctionnalités et le flux d'événements.

Si vous ne pouvez pas renvoyer de table de données, la bibliothèque renvoie une erreur. S'il est possible de renvoyer une table de données, mais qu'il existe un problème à signaler, la bibliothèque renvoie un avertissement en même temps que la table de données. Par exemple, la bibliothèque crée un avertissement dans les situations suivantes:

  • si une visualisation de requête fournit un LIMIT qui génère des données tronquées.
  • si une visualisation de requête demande 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 Commons de Jakarta peut être utilisée avec la plupart des systèmes de journalisation que vous avez peut-être déjà mis 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 Commons Jakarta.

Lorsqu'une exception est levée, les 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.