[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

remote object rights problem

Dave Thornley

6/15/2004 11:04:00 AM

Hi All,

I'm getting a bit confused about the identity remote objects are
executed under.

I've written a service that hosts a remoteable object, and a client that
can access it - all this works OK. Both host and client run on the same
machine, the host service is configured to run as localsystem.

The aim of the service is to allow actions to be executed with
localsystem rights, however, when I connect to the remote object I have
the same rights as I do in the client application. Calling
WindowsIdentity.GetCurrent().Name in the remote object returns my own
username.

I've also found that if I stop the service, the client will still create
an instance of the remote object, even though should (I think) be
unavailable...

Based on what I've read this the remote object should be running with
localsystem rights, however, this doesn't appear to be the case.

Am I totally misunderstanind .NET remoting or have I got a the
confiuration wrong somewhere? Any help would be gratefully received

cheers

dave
3 Answers

Sunny

6/15/2004 2:01:00 PM

0

Hi,

are you loging at server side to see if the server instaniates the
object? If something is wrong with the configuration, the client may
create local object.

See more inline:

In article <#BjrwhsUEHA.3420@TK2MSFTNGP12.phx.gbl>,
d.h.thornley@shu.ac.uk says...
> Hi All,
>
> I''ve also found that if I stop the service, the client will still create
> an instance of the remote object, even though should (I think) be
> unavailable...

The client does not connect to the server until first method call. What
you see is, that the proxy to the remote object is created, it always
succeeds. But if you try to make a method call, and server is not
running, it will fail. And ... if it succeeds, that means that you are
dealing with a local instance, and something in the configuration is
wrong.

>
> Based on what I''ve read this the remote object should be running with
> localsystem rights, however, this doesn''t appear to be the case.
>
> Am I totally misunderstanind .NET remoting or have I got a the
> confiuration wrong somewhere? Any help would be gratefully received

There is no way to tell you if you have something wrong without code :)

But, you may put some logging in the constructor of the remote object,
just to see where it is instaniated.

>
> cheers
>
> dave
>

Cheers
Sunny

Dave Thornley

6/16/2004 7:42:00 AM

0

Sunny wrote:

> Hi,
>
> are you loging at server side to see if the server instaniates the
> object? If something is wrong with the configuration, the client may
> create local object.
>
> See more inline:
>
> In article <#BjrwhsUEHA.3420@TK2MSFTNGP12.phx.gbl>,
> d.h.thornley@shu.ac.uk says...
>
>>Hi All,
>>
>>I''ve also found that if I stop the service, the client will still create
>>an instance of the remote object, even though should (I think) be
>>unavailable...
>
>
> The client does not connect to the server until first method call. What
> you see is, that the proxy to the remote object is created, it always
> succeeds. But if you try to make a method call, and server is not
> running, it will fail. And ... if it succeeds, that means that you are
> dealing with a local instance, and something in the configuration is
> wrong.
>
>
>>Based on what I''ve read this the remote object should be running with
>>localsystem rights, however, this doesn''t appear to be the case.
>>
>>Am I totally misunderstanind .NET remoting or have I got a the
>>confiuration wrong somewhere? Any help would be gratefully received
>
>
> There is no way to tell you if you have something wrong without code :)
>
> But, you may put some logging in the constructor of the remote object,
> just to see where it is instaniated.
>
>
>>cheers
>>
>>dave
>>
>
>
> Cheers
> Sunny

Fantasic - thanks for that. I didn''t know the object could get created
locally. Tinkering with the .config files sorted it out.

cheers

dave

Sunny

6/16/2004 2:23:00 PM

0

Hi,
glad to help you.

Btw, I''d recommend to use abstract class or interface approach. That way
the local creation of the object will be impossible, and you will always
know that something in config is wrong. And you are not shipping your
remote code to clients, which is good.

Sunny

In article <eNt51V3UEHA.712@TK2MSFTNGP11.phx.gbl>,
d.h.thornley@shu.ac.uk says...
> Sunny wrote:
>
> > Hi,
> >
> > are you loging at server side to see if the server instaniates the
> > object? If something is wrong with the configuration, the client may
> > create local object.
> >
> > See more inline:
> >
> > In article <#BjrwhsUEHA.3420@TK2MSFTNGP12.phx.gbl>,
> > d.h.thornley@shu.ac.uk says...
> >
> >>Hi All,
> >>
> >>I''ve also found that if I stop the service, the client will still create
> >>an instance of the remote object, even though should (I think) be
> >>unavailable...
> >
> >
> > The client does not connect to the server until first method call. What
> > you see is, that the proxy to the remote object is created, it always
> > succeeds. But if you try to make a method call, and server is not
> > running, it will fail. And ... if it succeeds, that means that you are
> > dealing with a local instance, and something in the configuration is
> > wrong.
> >
> >
> >>Based on what I''ve read this the remote object should be running with
> >>localsystem rights, however, this doesn''t appear to be the case.
> >>
> >>Am I totally misunderstanind .NET remoting or have I got a the
> >>confiuration wrong somewhere? Any help would be gratefully received
> >
> >
> > There is no way to tell you if you have something wrong without code :)
> >
> > But, you may put some logging in the constructor of the remote object,
> > just to see where it is instaniated.
> >
> >
> >>cheers
> >>
> >>dave
> >>
> >
> >
> > Cheers
> > Sunny
>
> Fantasic - thanks for that. I didn''t know the object could get created
> locally. Tinkering with the .config files sorted it out.
>
> cheers
>
> dave
>