I think checking HasPermission on a case by case basis is probably the better way to go. It allow the behavior when permission is not available to be determined appropriately in context.
For example: * When iterating over a collection of topics using Select, any topic that the user doesn't have permission for gets excluded. * When attempting to include one topic in another topic, the text "Topic can not be read: [topicname]" appears instead of the topic. (This is just an example to illustrate the point; I'm not proposing this particular result in this case). Now, specifically with respect to Select and Collect: I understand that the processing block that gets invoked for each item may perform operations other than read. I was suggesting that the very act of iterating over a topic was "performing a read" but I guess I see your point: this is not really a read operation so shouldn't be inherently restricted by having read permission. Perhaps it would make sense to do the permission checks in the places where reading is actually happening (e.g. when a property is accessed). Is that what you're suggesting? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of John Davidson > Sent: Monday, October 01, 2007 3:51 AM > To: FlexWiki Users Mailing List > Subject: Re: [Flexwiki-users] DenyRead and WikiTalk > > 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 ------------------------------------------------------------------------- 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
