The calls to BELArrary::Select and Collect are highly generalized methods which do not allow for a HasPermission call consistently within the stack.
In most cases dealing with access to topic information there are calls in the stack going through NamespaceManager where it is possible to add HasPermission calls. Craig has put a number of them here already. I would add HasPermission to NamespaceManager::GetTopicProperties and TextReaderForTopic. Using the try/catch block in BELArray worked exactly as expected with the performance hit the only downside. Using the HasPermission prevents the error condition that caused this conversation, but it allows the Name of the topic to be included when it would not be using the try/catch block. The inclusion of the topic name that a user does not have access to in a list is probably acceptable, given that the user is not able to access the actual topic content. John Davidson On 9/30/07, Craig Andera <[EMAIL PROTECTED]> wrote: > No, it's not correct. I'm suggesting that the implementation of > Collect/whatever call HasPermission - no changes to the way the > AuthorizationProvider works. > > There's still a slight chance for an exception due to race conditions > (someone denies permission on a topic after we call HasPermission but before > we call TextReaderForTopic or whatever), but in the absence of either > transactions or support for concurrent programming in WikiTalk (and we're > not going there) then I think it's the best we can do. And the race should > be extremely rare in any event. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flexwiki-users
