>From an off-line conversation between Craig and me on security setup issues.... Derek, you got dragged into this near the end so I wanted to include you and everyone else :)
On 9/11/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > right now, if there is a > > security setup problem and a successful login, then the system just > > blows chunks everywhere with no indication that it is a security > > problem. What happens is just that the calls > > Federation.CurrentNamespaceManager (or whatever it is called) just > > returns up null if the security tests fail. None of the higher up code > > is setup to handle these nulls. > > > > I'm guessing that you'd already realized this, but it is pretty ugly > > from a users standpoint. For example, I'd accidentally given > > permissions in flexwiki.config with "role:njones" instead of > > "user:njones" with my forms authentication. As soon as I reload the > > flexwiki.config app and login successfully, the site is completely > > broken. I get null pointers on every single activity. Even if I look > > at the config file and see my problem, I can't get back to the admin > > page to reload the flexwiki.config. In the end I have to bounce the > > app pool and restart the browser to clean up stuff. > > > > I've got a couple more thoughts on the situation, but I gotta head out > > to the office and I'd like to get your take on what I have so far.... > > Yeah, this is a real problem. I had to make some small-scale changes in the > UI to accommodate this for other scenarios - stuff like catching > FlexWikiAuthorizationException instead of just blowing up when iterating > over the list of topics. But I never did a comprehensive review of the web > app, because basically all my work has been focused on making FlexWiki work > *at all* after the changes I made. :) > > What I'd like to see is that the admin pages become *much* more resilient in > the face of load failures. Derek is going to be whipping up the page that > lets you edit and reload the config file, and I think we're going to have to > code it such that you can still run that page even if the Federation > completely fails to load. > > > This would go a long way to making it possible to recover. It doesn't help with the ugliness of what happens at runtime on the flexwiki site, but I'd say the minimum is to be able to get through to the admin pages. I'm thinking that these will primarily just need to be coded to accomodate the possibility that the Thread.CurrentPrincipal may not have any privileges at all inside the wiki itself. It is very easy to get yourself in a situation where the authorization rules and the authenticated user just don't match up. We need to be able to recover without recycling the app. Derek, is this snippet of the conversation enough to make the problem understandable? If not, I can go into more detail.... -nathan ------------------------------------------------------------------------- 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
