The way the block processes doesn't always call Read for the topic. It does always check at the AuthorizationProvider, but Craig doesn't want any changes made there. I have removed the try/catch from Select and Collect and begun replacing that with various HasPermission in NamespaceManager. I need to add at least one more HasPermission there and also one in the Formatter for IncludeTopic.
By having all the correct calls marked with HasPermission then I seem to get get the proper results, but before I finish checking it in I need to conduct more tests to make sure there are no adverse side effects. John Davidson On 9/30/07, David Ornstein <[EMAIL PROTECTED]> wrote: > 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 > > Flexwiki-users@lists.sourceforge.net > > 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 > Flexwiki-users@lists.sourceforge.net > 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 Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
