The library "HasAccess"-method will be called for each node in the scope. The current implementation of the HasAccess-method looks like this:
..yada..
if (Member.IsLoggedOn()) return Access.HasAccess(NodeId, Path, Membership.GetUser());
..yada..
This means that the call will fetch the get user from the Membership-provider once for each node in the tree. I've solved this by adding caching to the membership provider, but would'nt it be better to store the current user in a private field and reuse in some way?
Disclaimer: I'm not a .NET guy, so I don't know if there's something in there that'll work - I just have a couple of XSLT bits:
Although I rarely use it, I know you have a reason to use the HasAccess() method, but atleast the XPath could in general be sped up by making sure it doesn't travel to any nodes it doesn't need to, e.g.: the //* selector really selects every single node in the tree, which may cause an initial bottleneck of itself.
If you only need to test permissions on a specific branch of the site (say, the "Secrets" section) you could do something like this, to only perform the call for those nodes:
The selector $siteRoot//*[@isDoc] could be further optimized with any additional knowledge about the tree, e.g. if all nodes to process are of documenttype Textpage, be sure to use that too (i.e.: $siteRoot//Textpage)-
Thanks for the input! I think that this XPath can be improved but the underlaying problem is the fact that the implementation will go all the way to the db for each node that it has to evaluate. For example, niether of the UmbracoMembershipProvider and the SqlMembershipProvider caches the response from the GetUser-method.
When I added caching to my custom membership provider the loadtime went from 30 sec to 0.5 sec. In other words - the HasAccess method should keep one instance of the current member to reuse for each node. Question is how...?
Yes, I was about to add it to the issue tracker but decided to try the forum first to see if I missed something - sometimes the issue is my implementations =D
Calling library.HasAccess is slow
I'm running this piece of XSLT:
$currentPage/ancestor-or-self::*[@isDoc][@level = 1]//*[@isDoc][umbraco.library:HasAccess(@id, @path) = true()]
The library "HasAccess"-method will be called for each node in the scope. The current implementation of the HasAccess-method looks like this:
..yada..
if (Member.IsLoggedOn())
return Access.HasAccess(NodeId, Path, Membership.GetUser());
..yada..
This means that the call will fetch the get user from the Membership-provider once for each node in the tree. I've solved this by adding caching to the membership provider, but would'nt it be better to store the current user in a private field and reuse in some way?
Maybe solve like this: http://stackoverflow.com/questions/4492561/how-to-manage-multiple-calls-to-membership-getuser-efficiently
?
Hi Markus,
Disclaimer: I'm not a .NET guy, so I don't know if there's something in there that'll work - I just have a couple of XSLT bits:
Although I rarely use it, I know you have a reason to use the HasAccess() method, but atleast the XPath could in general be sped up by making sure it doesn't travel to any nodes it doesn't need to, e.g.: the //* selector really selects every single node in the tree, which may cause an initial bottleneck of itself.
If you only need to test permissions on a specific branch of the site (say, the "Secrets" section) you could do something like this, to only perform the call for those nodes:
<xsl:variable name="siteRoot" select="$currentPage/ancestor-or-self::*[@level = 1]" /> <xsl:variable name="nodes" select="$siteRoot//*[@isDoc]" /> <xsl:template match="/"> <xsl:apply-templates select="$nodes" /> </xsl:template> <xsl:template match="*[@isDoc]" name="output"> <!-- Usual stuff for every node --> </xsl:template> <!-- Nodes in the Secrets section --> <xsl:template match="Secrets/*[@isDoc]" priority="1"> <xsl:if test="umbraco.library:HasAccess(@id, @path)"> <xsl:call-template name="output" /> </xsl:if> </xsl:template>The selector $siteRoot//*[@isDoc] could be further optimized with any additional knowledge about the tree, e.g. if all nodes to process are of documenttype Textpage, be sure to use that too (i.e.: $siteRoot//Textpage)-
/Chriztian
Hi Chriztian!
Thanks for the input! I think that this XPath can be improved but the underlaying problem is the fact that the implementation will go all the way to the db for each node that it has to evaluate. For example, niether of the UmbracoMembershipProvider and the SqlMembershipProvider caches the response from the GetUser-method.
When I added caching to my custom membership provider the loadtime went from 30 sec to 0.5 sec. In other words - the HasAccess method should keep one instance of the current member to reuse for each node. Question is how...?
Oh my, that sounds horribly inefficient...
Have you checked the Issue Tracker for any previous reports of this? I'd say that's an obvious contender for a fix...
/Chriztian
Yes, I was about to add it to the issue tracker but decided to try the forum first to see if I missed something - sometimes the issue is my implementations =D
is working on a reply...