Re: 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=DEVDEV
_______________________________________________
Flexwiki-users mailing list
Flexwiki-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki
-users

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: flexwiki-users-bounceslists.sourceforge.net
[mailto:flexwiki-users-bounceslists.sourceforge.net] 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.p
hp?page=join.php&p=sourceforge&CID=DEVDE
V
_______________________________________________
Flexwiki-users mailing list
Flexwiki-userslists.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-userslists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flexwiki
-users