I may still be missing the whole picture but
OperationContext oc = OperationContext.Current;
ServiceSecurityContext ssc = oc.ServiceSecurityContext;
string client = ssc.PrimaryIdentity.Name;
This will get you the name of the currently logged in user, which from
what I'm reading is what you need. About detecting closing of the app,
I'm not exactly sure how you'd want to detect it, but custom lifestyle
with access to the user name and with trigger to release upon user exit
sounds like a reasonable way to go.
Krzysztof
On 18/04/2011 8:34 AM, Adam Langley wrote:
Thats not all I need though - I suppose its quite complicated to explain.
My goal is to have a windows-service which exposes endpoints over net-pipe,
which can be accessed by any process on the local machine to utilise
centralized services.
The service instance returned by the windows-service will depend on the
user-account of the caller.
A user who terminates their application process (which is a client of the
windows-service) will NOT have his worker objects destroyed because they are
keyed (lifestyle) against their user account, not the process-id. BUT if they
log out of the computer, then castle will destroy all their component instances.
I can see that this functionality has many tendrils that need to hook into
various different areas of responsibility with the castle infrastructure.
I would LIKE to be able to implement this using Castle paradigms so that it is
not implementation specific, but could be re-used easily in other, unrelated
projects.
Does that better explain where I am, and the depth of my proposition?
Thanks Krzysztof
Adam Langley
Please consider the environment before printing this email!
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Krzysztof Kozmic
Sent: Sunday, 17 April 2011 9:24 p.m.
To: [email protected]
Subject: Re: New WCF Facility Lifestyle
Sorry about the delay.
If all you need is authentication information isn't this available from
Thread.CurrentPrincipal or from OperationContext.Current ?
Krzysztof
On 14/04/2011 10:24 AM, Adam Langley wrote:
Absolutely, that would be analogous to my goals - except that nothing in the
WCF infrastructure will identify the windows session of the caller.
I was thinking that to achieve 'session identification' I would need to extend
windsor further - but perhaps I dont.
I expect the minimum I require, is that if my 'handler selector' is applied,
then the WCF endpoint must use Windows authentication. Then when a call comes
in, I can identify the windows account of the caller and use that to locate the
correct instance.
Does this sound like the right approach?
I still need some 'facility' running within castle to listen to log-off events
so that I can dispose of all instances associated with that user-session.
I just thought that because my 'extension' required so many different
functional facets, I would need to implement them in several different ways
(IHandlerSelector + Facility + Lifestyle, for example)
Adam Langley
Please consider the environment before printing this email!
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Krzysztof Kozmic
Sent: Thursday, 14 April 2011 9:38 a.m.
To: [email protected]
Subject: Re: New WCF Facility Lifestyle
Adam,
the way I saw it done usually, in multitenant applications is to have
the component registered for each tenant and use IHandlerSelector to
manage returning the right one.
Say you're using NHibernate and you have different databases for each
tenant and each database has it's own Session component which you pick
based on some information about what tenant is currently making the request.
Would that be fair to say you're in a similar situation?
On 13/04/2011 2:01 PM, Adam Langley wrote:
Dear group,
I have a requirement where-by I will have a Windows Service (running as
System) that publishes a component on net.pipe (for use by the local
machine only), but it must service multiple users logged on to the same
machine simultaneously.
It must create a 'singleton' instance per Windows User connected... so
the WCF layer will use integrated windows authentication.
When a user logs on to the machine, they will receive the same component
instance no matter how many times they connect/disconnect from the WCF
service - and no two users will ever share the same instance.
I was thinking that the best way to approach this would be a custom
lifestyle which creates a release policy per distinct windows user - the
component could even capture the global 'user logoff' event and dispose
that user's component at that time (I would really love this!).
What do you think of the concept, and what Castle extensibility points
would I rely on to implement this?
Adam Langley
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
