Smart clients

[MaSTeR]

I want to stream data from a server, the client is a smart client it I want
to be able to connect to a pc (eventually the pc it's been downloaded from).
The problem as you might expect is that the smart client doesn't have enough
permissions to open a socket, use remoting or even call a web service.
Anyone knows what to do ? (using caspol to loosen security works of course,
but it is not an option)

 

[Frank Hileman]

One solution is to use an .msi file to increase permissions for a specific
public key. This article explains the process.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms11122002.asp

Regards,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

 

[Nicholas Paldino [.NET/C# MVP]]

MaSTeR,

Actually, you should have permissions to call a web service (or open a
connection) to the machine that the client was downloaded from.

Also, with .NET 2.0, you should be able to install a security policy
which would allow more network access through ClickOnce.

Hope this helps.

 

[Richard Blewett [DevelopMentor]]

Of course, asking your clients to "please run this MSI" is not really any different from asking "please run this unmanaged .exe". You are asking them to execute arbitrary native code that runs outside of the auspices of CAS and so is, in of itself, a ricky practice for your users.

However, the problem is of course "what do you do instead?" And that has no easy answers if you need your client to elevate the permissions for your code to enable your application to run. There are solutions in managed networks (like domains) where security policy can be be controlled via the enterprise security policy level and distributes via some kind of file distribution system (Group Policy Objects, or system management software). But for non-centrally controlled networks the problem is harder.

Writing software that doesn't require elevated permissions is the best solution, just not always practical. At the moment the only other solution is to ask the user to manually set up policy changes (error prone) or, as you say, ask them to run an MSI.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

One solution is to use an .msi file to increase permissions for a specific
public key. This article explains the process.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms11122002.asp

Regards,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

 

[MaSTeR]

Na that's not feasible. I want to tun my smart client every where, even on
non-admin accounts that can't change permissioning.
I do not want to install anything or forc the user to change settings.

I achieved that very well with Java applets, where the VM tighten you inside
the sandbox that allows you anyway to open a socket to the server you've
downloaded the applet from.

Thanks for replying.
Filippo

 

[MaSTeR]

Of course, asking your clients to "please run this MSI" is not really any
different from asking "please run this unmanaged .exe". You are asking them
to execute arbitrary native code that runs outside of the auspices of CAS
and so is, in of itself, a ricky practice for your users.

Correct.

However, the problem is of course "what do you do instead?" And that has

no easy answers if you need your client to elevate the permissions for your
code to enable your application to run. There are solutions in managed
networks (like domains) where security policy can be be controlled via the
enterprise security policy level and distributes via some kind of file
distribution system (Group Policy Objects, or system management software).
But for non-centrally controlled networks the problem is harder.

Writing software that doesn't require elevated permissions is the best

solution, just not always practical. At the moment the only other solution
is to ask the user to manually set up policy changes (error prone) or, as
you say, ask them to run an MSI.As I said that's exactly the point, I am just surprised to learn this. Smart
client borned to achieve zero deployment but as a matter of fact you can't
create nothing more serious than a calculator

I wonder if .Net 2.0 will allow connection from and to the server "they
belong to" as Java does.

 

[MaSTeR]

MaSTeR,

Actually, you should have permissions to call a web service (or open a
connection) to the machine that the client was downloaded from.

Indeed, that I know.

Also, with .NET 2.0, you should be able to install a security policy
which would allow more network access through ClickOnce.

Hope this helps.

This is really awkward. I went at Microsoft for a smart client demonstration
and they told me you don't need to change any setting to call a web service.
In my experience I reckon this is false, but I might be doing something
wrong.

 

[Nicholas Paldino [.NET/C# MVP]]

You indicated in your initial post that you were not able to connect to
the host. The default CAS policy allows you to do this, but it could be
that your policy is different. Have you used the .NET administration tool
to check the policy?

 

[Ian Griffiths [C# MVP]]

This is really awkward. I went at Microsoft for a smart client
demonstration
and they told me you don't need to change any setting to call a web
service.
In my experience I reckon this is false, but I might be doing something
wrong.

This does work, but there are a couple of gotchas:

First, you can connect to a web service, but you cannot open any arbitrary
connection back. If you evaluate the permission set granted to an executable
in the Internet zone with the standard .NET Framework security settings in
place, you'll see that it has the Web Access permission but it does *not*
have the Socket Access permission.

So Nicholas isn't quite right - while he's correct to say that you will have
permissions to call a web service, he is wrong to suggest that you will have
permission to open a connection. It's more restrictive than that - you
won't be able to use a socket to connect back to the home machine, you'll
only be able to open an HTTP or HTTPS connection. (Of course that uses a
socket under the covers, but you won't be able to use the Socket class
directly.)

Second, you need to get the URL exactly right when connecting back. The way
the Web Access permission gets set up is that you have permission to connect
using HTTP or HTTPS back to your home server but *only* if you use the same
name for that server that you were downloaded from.

For example, I've got a little test harness running on my machine right now.
The smart client is written to use the fully qualified server name when
invoking the web service. If I launch the client using a URL with the fully
qualified server name, it is able to access the web service on the server.
But if I just use the local name, it doesn't work. In other words, because
the client is accessing the web service with:

http://mymachine.mydomain/App/Service.asmx

it only works if I launch the EXE like so:

http://mymachine.mydomain/App/SmartClient.exe

This works because when launched like this, the app's Web Access permission
looks like this:

(https|http)://mymachine\.mydomain/.*

If I try this:

http://mymachine/App/SmartClient.exe

then although it's pointing at the exact same machine, the attempt to use
the web service fails. That's because the Web Access permission now looks
like this:

(https|http)://mymachine/.*

but the client is still trying to use this:

http://mymachine.mydomain/App/Service.asmx


So in summary, you definitely can connect back to your home web server via
HTTP (but not using raw sockets), but you have to make sure you do so using
a URL that is consistent with the one used to launch your application in the
first place.

 

[MaSTeR]

Thank you a million times !
That worked !