Hmm. I guess I'm not sure I see this:
> The calls to BELArrary::Select and Collect are highly generalized > methods which do not allow for a HasPermission call consistently > within the stack. Why can't the loop just check for read permission for each topic before it evaluates the block in the loop? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of John Davidson > Sent: Sunday, September 30, 2007 9:20 AM > To: FlexWiki Users Mailing List > Subject: Re: [Flexwiki-users] DenyRead and WikiTalk > > 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 ------------------------------------------------------------------------- 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
