Thanks for your insight. It sounds like this should be doable in a few ways, which is the main thing I was looking to verify at this time (that the implementation was feasible)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Andera Sent: Tuesday, April 10, 2007 6:23 AM To: 'FlexWiki Users Mailing List' Subject: Re: [Flexwiki-users] FW 2.0 Security Integration Question OK, so I think I understand your scenario now. A few comments. * You don't necessarily have to plug in to the content provider filter chain. It would certainly work, but the other approach would be to put some code into global.asax to modify the current security context (Thread.CurrentPrincipal) based on the authenticated user and what's in the database. You'd just attach a bunch of roles to the user that would correspond to the permissions from the NC database. Of course, you'd have to have Allow and Deny statements in the topics themselves, which might get unwieldy - that's going to depend on details of your application. * Caching is currently disabled in the 2.0 bits. But even if it weren't, if you go the route of injecting into the content provider filter chain, I'd still suggest just hitting the database every time. Databases are faster than most people think - you might not even notice the extra difference, and if you can avoid having to get clever about optimization, you should. * Assuming you *do* need to optimize, I'd suggest waiting until I get the caching layer done. Because the filter chain looks like this: NamespaceManager <-> Security <-> Caching <-> Property Parsing <-> Built-in Topics <-> Physical Store So what you could do would be to add a provider that injects custom properties in between caching and property parsing, and they'd get cached for free. Plus, at that point the model for properties is abstract rather than lexical, so you wouldn't have to worry about syntax at all. You'd just do something like AddProperty("name", "value"). * Thinking about it, we probably don't need the filter chain to be dynamically pluggable. If you've got a custom build, you could just hardcode your new provider(s) into the default chain, the way I do it for all the providers now. Anyway, those are some ideas. ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
