[MOSS 3.0] User Permissions

[maniak]

Dames en heren,

Ik heb het nergens kunnen vinden dus vraag ik het hier maar. Op dit moment hebben wij een custom sitemap provider die het hoofdmenu voed met items. Deze menu items zijn security trimmed, of te wel, hij checked of iemand er rechten heeft voordat die het item toevoegd aan het menu.

Om te controlleren of iemand rechten heeft op een SPSite of SPWeb object heb je daarvoor een functie:
DoesUserHavePermissions.

Hier komt het probleem. Voordat je die functie kan aanroepen voor een SPSite of SPWeb moet je daarvoor een SPSite of SPWeb object aanmaken (en achteraf zelf disposen) maar dit is erg CPU en memory intensief. Hij bouwt namelijk alles op en niet alleen het deel voor de rechten.

Dit fenomeen zorgt ervoor dat het menu meerdere seconden erover doet om op te bouwen. Er is gekeken voor caching maar om dit nou te doen voor bijna 30.000 gebruikers is niet erg verstanding, plus, bij de eerste keer ophalen van het menu duurt het dus een paar seconden wat niet acceptabel is.

Zijn er andere mogelijkheden om door een sitecollection te ittereren en security te checken die een stuk sneller werkt?

[dj_vibri]

owever, deriving the Office SharePoint Server 2007 site map providers supplies several additional benefits such as navigation node caching and security trimming. Therefore, you should use the Office SharePoint Server 2007 caching and security trimming infrastructure instead of writing your own caching and security trimming in a custom provider by deriving from the default providers.

bron: http://windowssharepoints...ategory/sharepoint-menus/

en kan je misschien niet op voorhand even checken tot welk 'departement' oid de ingelogde gebruiker behoort en op basis hiervan een andere sitemap inladen? *met minder in te laden menu-items?*

[maniak]

dj_vibri schreef op donderdag 28 mei 2009 @ 14:29:
[...]


bron: http://windowssharepoints...ategory/sharepoint-menus/

en kan je misschien niet op voorhand even checken tot welk 'departement' oid de ingelogde gebruiker behoort en op basis hiervan een andere sitemap inladen? *met minder in te laden menu-items?*

Dat zou eventueel op te lossen zijn.. Maar het probleem doet zich ook voor bij een lijst die alle links toont van alle teamsites waar hij/zij lid is..

[dj_vibri]

en waarom geen gebruik maken van Caching?

Dit zal imo de eerste keer enige tijd in beslag nemen, maar nadien zal je SharePoint Farm wel vlotter draaien.

misschien ben je hier nog iets mee: http://blogs.msdn.com/ecm...-faster-with-caching.aspx

Vraagje: is je installatie stand-alone of is er een 'farm' opgezet?

offtopic:
Het is OFWEL WSS 3.0 OFWEL MOSS (2007)

[ Voor 10% gewijzigd door dj_vibri op 28-05-2009 14:44 ]

[maniak]

dj_vibri schreef op donderdag 28 mei 2009 @ 14:39:
en waarom geen gebruik maken van Caching?

Dit zal imo de eerste keer enige tijd in beslag nemen, maar nadien zal je SharePoint Farm wel vlotter draaien.

misschien ben je hier nog iets mee: http://blogs.msdn.com/ecm...-faster-with-caching.aspx

Vraagje: is je installatie stand-alone of is er een 'farm' opgezet?

Met zoveel gebruikers moet het wel een farm zijn.. we hebben 4 frontend, 2 app servers 2 db servers.

Kijk.. als een gebruiker de eerste keer een pagina wil openen en moet dan soms wel 15 sec wachten op een reply is totaal niet acceptabel, plus ook niet in lijn met het FO en/of TO, ook al zou het daarna sneller gaan. Het is niet uit te leggen.

Tevens doet zich het volgende probleem voor, veranderingen. Je kan niet zomaar een cache aanhouden van bv 8 uur terwijl er wijzigingen kunnen voordoen bij de rechten van objecten.

De enige cache die we op dit moment hebben is dat we de tree in zijn geheel in het geheugen hebben welke gebruikt wordt voor de security trimming als een gebruiker een pagina opent.