none
[SP2013] Accès refusé lors de la création d"une collection de site RRS feed

  • Question

  • Bonjour,

    Je tente de créer une collection de site dans la fonction ItemUpdated de mon Event Handler.

                    SPSecurity.RunWithElevatedPrivileges(delegate()
                    {
                        using (SPSite oSPSite = new SPSite(sUrlRootSite))
                        {
                            SPWebApplication oSPWebApplication = oSPSite.WebApplication;
                            SPSiteCollection oSPSiteCollection = oSPWebApplication.Sites;

                            if (oSPWebApplication.Sites[sUrlRelative] == null)
                            {
                                oSPSiteCollection.Add(sUrlSite, sSiteName, String.Empty, 1036, sSiteTemplate, sAdminColl, string.Empty, string.Empty);
                                oSPWebApplication.Update();
                            }
                        }
                    });

    J'ai un accès refusé sur la fonction oSPSiteCollection.Add(...).
    Selon mes recherches, l'erreur proviendrait de mon compte d'application pool qui n'a pas le droit d'écrire dans la base de conf.
    Effectivement, lorsque je fais tourner mon application pool avec le compte farm, je n'ai plus le problème.
    Pourtant, il me semble que ce n'est pas recommandé de faire tourner les pools d'applications avec le compte farm.

    J'ai tenté de faire:
    - une impersonation avec le SystemAccount => même erreur
    - de lancer ma création avec un timerjob => accès refusé lors de l'update de mon job

    Merci de m'aider, help...



    mardi 13 août 2013 15:52

Réponses

  • Bonjour

    c'est un peu normal, l'objectif / raison d’être des collections de sites sont de pouvoir isoler les unes des autres... donc un code dans une collection de sites qui manipule des données d'une autre collection doit nécessiter des privilèges importants !

    Concernant le RunWithElevated, il ne permet ni plus ni moins d'assurer que le code tourne ds le contexte d'identité du pool et non de l'utilisateur courant....

    Ce  type de code devrait en fait se trouver dans une feature de type farm, tournant donc sur le site de central admin qui lui tourne avec un pool dont l'identité est généralement le compte de la ferme....

    A minima vous avez 2 options :

    1. changer l'identité du pool de votre webapp en lui donnant un compte qui a les droits dbOwner sur la base SharePoint_Config (pas obligé que ce soit le compte de la ferme, ça peut être un autre). Mais effectivement cela ouvre des potentiels failles sur cette webapp, donc pas idéal...
    2. changer la conception de votre applicatif pour "déporter" la création de la collection à proprement dit dans un timerjob par exemple qui lui tournera ds le contexte "Farm" et donc tournera avec le compte de la ferme....

    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    lundi 19 août 2013 08:45
  • Bonjour,

    Tout d'abord merci pour ta réponse.

    J'avais justement tenté d'instancier un timerjob, qui lui allait faire le boulot, depuis mon event handler mais j'ai un accès refusé lorsque je fais mon .update sur mon objet timerjob.

    Finalement j'ai utilisé le service SelfServiceCreateSite pour créer ma collection de site, ça fonctionne.

    Merci à tous.

    lundi 19 août 2013 16:57

Toutes les réponses

  • Bonjour,

    et avec un ?

    oSPWebApplication.AllowUnsafeUpdates = true;


    mercredi 14 août 2013 12:35
    Modérateur
  • Bonjour,

    Sauf erreur de ma part, la propriété AllowUnsafeUpdates n'existe pas sur l'objet SPWebApplication.

    J'ai tenté quand même de mettre cette propriété sur mon objet SPSiteCollection oSPSite mais j'ai la même erreur..

    mercredi 14 août 2013 14:04
  • Bonjour

    c'est un peu normal, l'objectif / raison d’être des collections de sites sont de pouvoir isoler les unes des autres... donc un code dans une collection de sites qui manipule des données d'une autre collection doit nécessiter des privilèges importants !

    Concernant le RunWithElevated, il ne permet ni plus ni moins d'assurer que le code tourne ds le contexte d'identité du pool et non de l'utilisateur courant....

    Ce  type de code devrait en fait se trouver dans une feature de type farm, tournant donc sur le site de central admin qui lui tourne avec un pool dont l'identité est généralement le compte de la ferme....

    A minima vous avez 2 options :

    1. changer l'identité du pool de votre webapp en lui donnant un compte qui a les droits dbOwner sur la base SharePoint_Config (pas obligé que ce soit le compte de la ferme, ça peut être un autre). Mais effectivement cela ouvre des potentiels failles sur cette webapp, donc pas idéal...
    2. changer la conception de votre applicatif pour "déporter" la création de la collection à proprement dit dans un timerjob par exemple qui lui tournera ds le contexte "Farm" et donc tournera avec le compte de la ferme....

    Blog Sharepoint : www.paslatek.net Twitter : @LimozinLionel

    lundi 19 août 2013 08:45
  • Bonjour,

    Tout d'abord merci pour ta réponse.

    J'avais justement tenté d'instancier un timerjob, qui lui allait faire le boulot, depuis mon event handler mais j'ai un accès refusé lorsque je fais mon .update sur mon objet timerjob.

    Finalement j'ai utilisé le service SelfServiceCreateSite pour créer ma collection de site, ça fonctionne.

    Merci à tous.

    lundi 19 août 2013 16:57