One other approach that might be the simplest would be to have the original loop start not with all topics that exist but only those that can be read.
Can we see the original WikiTalk fragment that caused the issue? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:flexwiki- > [EMAIL PROTECTED] On Behalf Of Craig Andera > Sent: Friday, September 28, 2007 11:20 AM > To: 'FlexWiki Users Mailing List' > Subject: Re: [Flexwiki-users] DenyRead and WikiTalk > > > I think the correct behavior should be that when the WikiTalk finds > it > > is not able to read a Topic it should ignore that particular Topic, > > rather than return an error that stops the process. > > So, thinking about it a little more, I'm not sure whether this will > work or > not. Hopefully so, but let me "talk" through it a bit. > > The logical model that the engine provides is that if you're denied > read to > a particular topic, you're allowed to know of its existence, but not to > find > out anything else about it: contents, last modification date, author, > etc. > That means that if you have WikiTalk that does a double loop over all > topics > and then emits all the modification dates of that topic, you could get > into > a situation where the first loop returns a all the topics - even the > ones > you can't read - but the second loop chokes trying to figure out the > modification date of one or more of them. Complicating matters further > is > the fact that a change of permission while iterating might mean that > you're > able to see some properties but not others. > > What this means to me is that it's not clear whether it makes any sense > to > talk about "pretending it doesn't exist". If you've already written the > beginning of a row in a table that you're emitting via WikiTalk, what > do you > do if you can't read the property that corresponds to the third column? > > There are a few possibilities that I can think of: > > 1) Be sure to return default values for any query that results in an > AuthorizationException. For instance, Modified might come back > DateTime.MinValue. > 2) Filter every list of topics by calling HasPermission on the whole > list, > removing any topic that doesn't allow Read. Note that this is still > susceptible to the race condition mentioned above. Maybe that's okay. > > Of course, what would be really great [1] would be providing an > IQueryable<> > implementation over the topic store... :) > > [1] Totally kidding. One rewrite of the entire engine is enough for me > this > decade, thank you. > > > > ----------------------------------------------------------------------- > -- > 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
