Sharing objects between Web and console

[baylor]

Are there are any best practices or guidance on how to share an object
between the Web world and the non?

Here's my situation: i have one object (a security profile containing
IPrincipal + some other stuff) that almost every other object in my system
uses (methods have role-based security). The object is specific to a user.
User A logs in, gets authenticated, his security profile gets shoved into
Session, each page he goes to retrieves it from Session, each object he calls
also retrieves it from Session, each object that object calls retrieves it
from Session and so on and so on

We are now writing batch processes. Every night the batch cycle calls an EXE
that does a bunch of stuff with the database (ex - a user's last day was
scheduled to be Friday, on Friday the employee termination code runs). This
app should use all our business objects. Which rely on an object (the
security profile) that's currently in Session state. So that ain't gonna work

i know i'm not the first person to run into something like this. So the
question is, how do i share objects between ASP.NET and non-ASP?

Here are my thoughts:

1. Use Thread.CurrentPrincipal. Both Web and non-Web apps have access to
this. Make my own security object implement IPrincipal and recast on
retrieve. Works great for WinForms, complete failure for ASP.NET. ASP.NET
wipes out the principal object on every page call and creates a new principal
containing only the user's name - no role data, nothing that was in the
security profile. So this won't work

2. Get the security profile from a class that can tell if it's a console or
ASP.NET app (don't know how but i'm sure it's possible). Have it pull from
Thread.CurrentPrincipal for console, Session for ASP.NET

3. Get user ID from Thread.CurrentPrincipal. Use that to relook up all the
security info every time it's needed (takes roughly 5 stored procedures calls
against two databases). Given that we use a lot of objects, this could lead
to a bunch of database calls

4. Manually pass the security profile from object to object and method to
method. Talk about ugly... Also not very secure, but then i'm thinking
nothing that uses Forms Authentication is likely to be

5. Make a facade the user can call, make every other class internal, have
the facade check credentials (via a database look up). This might be an issue

6. Beg you guys for advice

i've chosen option 6 :)

[Patrice]

Not sure but for now it looks like to me that the problem is that your
classes are explicitely fetching the object you need from a session variable
introducing then a dependency on the overall context of execution for these
classes (ie. they breaks in non ASP.NET applications).

You could :
- feeding class(es ?) with the object instead of letting them fetch the
object from their environment (by picking this one from a session variable)

If you need to pass this around, this is perhaps because of a problem in
your programming model. You could perhaps for example add a "context" object
to your programming model. This context would be shared by all security
related classes...

You could also approach this by using a "provider" whose purpose is to
provide those classes with the object you need. You'll have a provider for
ASP.NET and a provider for non ASP.NET applications...

Patrice

--

"baylor" <ba****@discussions.microsoft.com> a écrit dans le message de
news:77**********************************@microsof t.com...

Are there are any best practices or guidance on how to share an object
between the Web world and the non?

Here's my situation: i have one object (a security profile containing
IPrincipal + some other stuff) that almost every other object in my system
uses (methods have role-based security). The object is specific to a user.
User A logs in, gets authenticated, his security profile gets shoved into
Session, each page he goes to retrieves it from Session, each object he calls also retrieves it from Session, each object that object calls retrieves it
from Session and so on and so on

We are now writing batch processes. Every night the batch cycle calls an EXE that does a bunch of stuff with the database (ex - a user's last day was
scheduled to be Friday, on Friday the employee termination code runs). This app should use all our business objects. Which rely on an object (the
security profile) that's currently in Session state. So that ain't gonna work
i know i'm not the first person to run into something like this. So the
question is, how do i share objects between ASP.NET and non-ASP?

Here are my thoughts:

1. Use Thread.CurrentPrincipal. Both Web and non-Web apps have access to
this. Make my own security object implement IPrincipal and recast on
retrieve. Works great for WinForms, complete failure for ASP.NET. ASP.NET
wipes out the principal object on every page call and creates a new principal containing only the user's name - no role data, nothing that was in the
security profile. So this won't work

2. Get the security profile from a class that can tell if it's a console or ASP.NET app (don't know how but i'm sure it's possible). Have it pull from
Thread.CurrentPrincipal for console, Session for ASP.NET

3. Get user ID from Thread.CurrentPrincipal. Use that to relook up all the
security info every time it's needed (takes roughly 5 stored procedures calls against two databases). Given that we use a lot of objects, this could lead to a bunch of database calls

4. Manually pass the security profile from object to object and method to
method. Talk about ugly... Also not very secure, but then i'm thinking
nothing that uses Forms Authentication is likely to be

5. Make a facade the user can call, make every other class internal, have
the facade check credentials (via a database look up). This might be an issue
6. Beg you guys for advice

i've chosen option 6 :)