none
Validation de la sécurité des pages Web RRS feed

  • Question

  • Bonjour,

    Dans la centrale d'administration, on a la possibilité d'activer ou de désactiver la "validation de la sécurité des pages Web" dans la partie "Paramètres généraux de l'application Web".
    Je voudrais connaitre la signification de cette "Validation", il s'agit pour Sharepoint de valider quoi par rapport à quoi et à quel moment ?
    Désolé si ma question est théorique, il se trouve que j'ai eu des erreurs liées à cette validation que j'ai toutes réglées avec "du bricolage" et je pense qu'en comprenant le quid de cette validation je pourrais apporter de meilleurs solutions.

    Merci par avance
    vendredi 27 février 2009 15:47

Réponses

  • Bonjour,

    L'utilité de ce mécanisme est indirectement expliquée ici : http://support.microsoft.com/kb/888828

    Il vérifie que les requetes http de type POST, correspondant à des actions utilisateur, sont bien autorisées par SharePoint.

    Par exemple lors du click sur OK pour l'ajout d'un élément dans une liste SharePoint, SharePoint va vérifier dans la requete http correspondante que celle-ci a bien été envoyée depuis la page d'ajout d'élément, il y a moins de X minutes.

    Pour résumer, lorsque SharePoint sert une page permettant une action utilisateur, il prévoit que cette action peut avoir lieu pendant les X minutes suivantes, de la part de l'utilisateur courant. Si une action n'est pas prévue, elle est considérée comme invalide et génère une erreur.

    Il n'est donc pas conseillé de désactiver cette validation.


    Concernant les erreurs que vous avez eu, elles apparaissent souvent dans des pages custom dont le code aboutit à la modification de données SharePoint, et peuvent être corrigées en ajoutant le contrôle FormDigest dans l'aspx : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.formdigest.aspx 
    Ceci est une best practice et permet de ne pas avoir recours à la désactivation de la validation de la sécurité des pages web.

    Si cette technique n'est pas applicable ou ne fonctionne pas, pourriez-vous nous en dire plus sur les erreurs en question ?
    • Proposé comme réponse Arnault Nouvel dimanche 1 mars 2009 11:21
    • Marqué comme réponse Elhadi lundi 2 mars 2009 14:36
    dimanche 1 mars 2009 11:19
  • Une solution consisterait à désactiver temporairement la validation :

    SPSecurity.RunWithElevatedPrivileges(delegate(){     
       using(SPSite site = new SPSite(SPContext.Current.Site.ID)){     
               
          SPWebApplication webApp = site.WebApplication;        
          webApp.FormDigestSettings.Enabled = false;        
           
          //Exécutez ici le code rebelle        
           
          webApp.FormDigestSettings.Enabled = true;        
        
       }     
    });   

    Est-ce que cela corrige votre problème ?
    • Marqué comme réponse Elhadi vendredi 6 mars 2009 19:31
    vendredi 6 mars 2009 08:30
  • Enfin on trouvé une solution plus simple, mais il fallait vraiment là trouver celle-là !
    Dans la methode Load de la page ASPX on doit ajouter le code suivant :

    If IsPostBack Then 
       Microsoft.SharePoint.Utilities.SPUtility.ValidateFormDigest()  
    End If 

    Moi même je ne comprend pas pourquoi la validation réussi lorsqu'on la déclenche explicitement comme ça, mais bon l'essentiel...
    • Marqué comme réponse Elhadi jeudi 19 mars 2009 17:36
    jeudi 19 mars 2009 17:36

Toutes les réponses

  • Bonjour,

    L'utilité de ce mécanisme est indirectement expliquée ici : http://support.microsoft.com/kb/888828

    Il vérifie que les requetes http de type POST, correspondant à des actions utilisateur, sont bien autorisées par SharePoint.

    Par exemple lors du click sur OK pour l'ajout d'un élément dans une liste SharePoint, SharePoint va vérifier dans la requete http correspondante que celle-ci a bien été envoyée depuis la page d'ajout d'élément, il y a moins de X minutes.

    Pour résumer, lorsque SharePoint sert une page permettant une action utilisateur, il prévoit que cette action peut avoir lieu pendant les X minutes suivantes, de la part de l'utilisateur courant. Si une action n'est pas prévue, elle est considérée comme invalide et génère une erreur.

    Il n'est donc pas conseillé de désactiver cette validation.


    Concernant les erreurs que vous avez eu, elles apparaissent souvent dans des pages custom dont le code aboutit à la modification de données SharePoint, et peuvent être corrigées en ajoutant le contrôle FormDigest dans l'aspx : http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.formdigest.aspx 
    Ceci est une best practice et permet de ne pas avoir recours à la désactivation de la validation de la sécurité des pages web.

    Si cette technique n'est pas applicable ou ne fonctionne pas, pourriez-vous nous en dire plus sur les erreurs en question ?
    • Proposé comme réponse Arnault Nouvel dimanche 1 mars 2009 11:21
    • Marqué comme réponse Elhadi lundi 2 mars 2009 14:36
    dimanche 1 mars 2009 11:19
  • Bonjour,

    Merci pour votre réponse, j'ai enfin compris la signification de cette validation.

    Maintenant, j'ai affaire à ce problème et l'ajout de la balise FormDigest ne l'a pas réglé.
    Avant d'ajouter la balise FormDigest je suis allé voir le source de la page HTML généré et elle contenait déjà ceci :

    <input type="hidden" name="__REQUESTDIGEST" id="__REQUESTDIGEST" value="0xD2927A6AE4F99C8C006EE1990D4C2D90976E744B6E31072366D52041BC7F4445A61ABAA287B7A66A7A6B1035F511C440D2B432C4CE01E79442A485BD4C96E8FB,05 Mar 2009 16:49:09 -0000" />

    et aussi

    function WebForm_OnSubmit() {
    UpdateFormDigest('\u002f', 1440000);return _spFormOnSubmitWrapper();
    return true;
    }

    Et l'ajout de la balise FormDigest n'a rien changé au code HTML généré, je pense que quand la validation est activée Sharepoint ajoute implicitement une balise FormDigest.
    Quoiqu'ilen soit mon problème est resté le même. Et pour vous donner des infos sur ce que je fais : sachez qu'il s'agit d'une page web à laquelle on donne un chemin de répertoire et qui va importer du contenu à partir de ce répertoire, elle crée un objet SPimport lui définit quelques propriétés puis appele sa méthode import(), le problème se produit à ce moment là à mon avis.

    Avez-vous une autre piste à me proposer ?
    jeudi 5 mars 2009 17:02
  • Une solution consisterait à désactiver temporairement la validation :

    SPSecurity.RunWithElevatedPrivileges(delegate(){     
       using(SPSite site = new SPSite(SPContext.Current.Site.ID)){     
               
          SPWebApplication webApp = site.WebApplication;        
          webApp.FormDigestSettings.Enabled = false;        
           
          //Exécutez ici le code rebelle        
           
          webApp.FormDigestSettings.Enabled = true;        
        
       }     
    });   

    Est-ce que cela corrige votre problème ?
    • Marqué comme réponse Elhadi vendredi 6 mars 2009 19:31
    vendredi 6 mars 2009 08:30
  • Merci, je vais tester ça tantôt et je vous dirais ce qu'il en est.
    Mais dès maintenant, je suis un pti peu sceptique, car dans ton exemple le code rebelle doit utiliser des objet obtenu depuis les variables site ou webApp (Ex: site.Lists[0]) pour que cela fonctionne, or je ne sais pas si vous connaissez l'objet SPImport, ce dernier n'est pas obtenu depuis ces deux variables mais il est utilisé plutot comme ça :

    dim import as new SPImport()  
    import.settings = ...  
    import.site = "Url sous forme de string, et non pas objet SPSite" 
    import.import() 

    Donc je ne sais pas si ça va marcher, je vous rendrais la réponse.
    vendredi 6 mars 2009 13:01
  • Merci infiniment, ton bou de code marche bien. Il suffit de lui ajouter deux webApp.update() au bon endroit. Voilà ce que ça donnerait :

    SPSecurity.RunWithElevatedPrivileges(delegate(){        
       using(SPSite site = new SPSite(SPContext.Current.Site.ID)){        
                  
          SPWebApplication webApp = site.WebApplication;           
          webApp.FormDigestSettings.Enabled = false;  
          webApp.update();     
              
          //Exécutez ici le code rebelle           
              
          webApp.FormDigestSettings.Enabled = true;           
          webApp.update();   
       }        
    });      
     

    Encore merci :)
    vendredi 6 mars 2009 19:30
  • Re,

    Nous venons de graduer la solution vers un nouveau serveur + sécurisé, et là erreur ! En effet, la tentative de modifier le paramètre génère une erreur de type accès refusé :

    webApp.FormDigestSettings.Enabled = false;     
    webApp.update();        
     

    ces instructions s'exécutent avec l'identité du pool puisqu'on a utilisé RunWithElevatedPrivileges.
    Ma question est la suivante : que sont les privilèges minimals que doit avoir le compte du pool pour qu'il puisse exécuter ces deux instructions.

    Que pouvez-vous me dire de plus sur les raisons de l'échec de cet exécution ?
    vendredi 13 mars 2009 19:54
  •  Bonjour,

    pour être honnête je n'ai jamais utilisé cette instruction, pourriez-vous me donner le message d'erreur exact ? Avec un peu de chance il devrait nous donner une piste sur ce qui manque.

    Pour l'instant je pense plus à un problème de configuration CAS qu'à un problème de compte.
    http://blogs.developpeur.org/anouvel
    lundi 16 mars 2009 10:40
  • Bonjour,

    Voilà le message d'erreur, c'est une page d'erreur sharepoint standard avec le lien revenir au site. En regardant la pile je n'arrive pas à déterminer s'il s'agit d'une restriction CAS ou bien de privilèges insuffisants pour le compte.

    Accès refusé.   à Microsoft.SharePoint.Administration.SPFormDigestSettings.set_Enabled(Boolean value)
       à Rrq.Web.PortailRRQ.OutilsGestionSite.ImportExportSelectif.Utilitaires.XsCaImportation.LancerImport()
       à Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
       à Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
       à Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
       à Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
       à Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
       à Rrq.Web.PortailRRQ.OutilsGestionSite.ImportExportSelectif.Utilitaires.XsCaImportation.importer()
       à Rrq.Web.PortailRRQ.OutilsGestionSite.XS7ImporterIndiv.btnImporter_ServerClick(Object sender, EventArgs e)
       à System.Web.UI.HtmlControls.HtmlInputButton.OnServerClick(EventArgs e)
       à System.Web.UI.HtmlControls.HtmlInputButton.RaisePostBackEvent(String eventArgument)
       à System.Web.UI.HtmlControls.HtmlInputButton.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
       à System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
       à System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
       à System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
       à System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
       à System.Web.UI.Page.ProcessRequest()
       à System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
       à System.Web.UI.Page.ProcessRequest(HttpContext context)
       à ASP._layouts_rrq_xs7importerindiv_aspx.ProcessRequest(HttpContext context)
       à System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
       à System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
    lundi 16 mars 2009 13:39
  • Bonsoir,

    toutes mes excuses, il faut un compte admin de la ferme pour jouer avec la propriété webApp.FormDigestSettings.Enabled;  

    J'essaie de reproduire le problème sur ma VM et je reviens vers toi.
    http://blogs.developpeur.org/anouvel
    lundi 16 mars 2009 21:29
  • OK merci beaucoup, en attendant votre retour je vais me préparer à un bras de fer avec l'équipe de sécurité :)
    mardi 17 mars 2009 00:44
  •  J'ai reproduis l'erreur et tout essayé pour la contourner, mais rien n'y fait !

    Une alternative viable : Mettre la fonctionnalité d'import dans un web service déployé sur un des serveurs de la ferme, le faire tourner avec un compte admin, et l'appeller depuis ta page SharePoint.

    Sinon, tu peux essayer la procédure expliquée ici : http://msdn.microsoft.com/fr-fr/library/cc768615.aspx
    Difficile à maintenir surtout si la ferme dispose de plusieurs frontaux, du coup je préfère la solution avec 1 seul web service.
    http://blogs.developpeur.org/anouvel
    mercredi 18 mars 2009 23:56
  • Merci pour votre aide et votre "jusqu'auboutisme" :)
    J'aimerais bien revenir à mon poste du 05/03/2009 ci-dessus pour vous demander pourquoi je continuais à avoir l'erreur de validation alors qu'il y avait bien le token dans ma page ASPX et que cette dernière est dans le répertoire 12 ?!
    jeudi 19 mars 2009 14:00
  •  FormDigest permet d'enregistrer la page un token indiquant que des modifications du site courant sont autorisées.

    Dans le cas présent, puisqu'il s'agit d'une opération d'ordre administrative, il est en plus vérifié que l'utilisateur courant (ou le compte de l'app pool pendant un RunWithElevatedPrivileges) a les droits d'admin. 

    L'erreur renvoyée en cas d'echec cette vérification a le même libellé dans les 2 cas.

    http://blogs.developpeur.org/anouvel
    jeudi 19 mars 2009 14:44
  • Enfin on trouvé une solution plus simple, mais il fallait vraiment là trouver celle-là !
    Dans la methode Load de la page ASPX on doit ajouter le code suivant :

    If IsPostBack Then 
       Microsoft.SharePoint.Utilities.SPUtility.ValidateFormDigest()  
    End If 

    Moi même je ne comprend pas pourquoi la validation réussi lorsqu'on la déclenche explicitement comme ça, mais bon l'essentiel...
    • Marqué comme réponse Elhadi jeudi 19 mars 2009 17:36
    jeudi 19 mars 2009 17:36