[.NET] Remoting : SecurityExceptions bij delegates

[whoami]

Ik ben wat aan het stoeien met .NET Remoting.

Ik heb een Server-applicatie, een server object en een client applicatie.

M'n server-object is afgeleid van de MarshalByRefObject class en heeft een member van het type event.
Die class ziet er in short zo uit:

code:

public class MyClass : MarshalByRefObject
{

  public event MyEvent;

  public MyFunction()
  {
     if( MyEvent != null )
     {
         MyEvent(this, new MyEventArgs(blaat, blaat));
     }
  }

}

In m'n server application, 'registreer' ik m'n object (en een channel) dan als volgt:

code:

HttpChannel aChan = new HttpChannel(aportnummer);
ChannelServices.RegisterChannel(aChan);

RemotingConfiguration.RegisterWellKnownServiceType(typeof(MyClass), "uri",
                                                  WellKnownObjectMode.Singleton);

Zoals je in bovenstaande code kunt zien, wil ik dat dat server-object als een singleton behandeld wordt.

In de client applicatie, maak ik dan een ref. naar een server object:

code:

MyClass test = (MyClass)Activator.GetObject(typeof(MyClass), "http://blaat/uri");

Daarna, wil ik een method aan m'n eventhandler toewijzen en daar gaat het fout:

code:

test.MyEvent += new MyReceiverHandler(aFunctionName);

Op die regel krijg ik dus een securityException

Het type System.DelegateSerializationHolder en de typen die hiervan zijn afgeleid hebben geen toestemming om op dit beveiligingsniveau te worden gedeserialiseerd.

Nu heb ik al mbhv de .NET configuration wizards m'n assemblies full trust gegeven, maar dat blijkt niet te werken.
Iemand een idee wat ik nog over het hoofd zie?

[mbravenboer]

Ik heb hier vrij lang geleden eens mee zitten spelen (beta 1.0) en toen bleek dat de Client een MarshalByRefObject moet zijn. Dit is overigens wel begrijpelijk, omdat er natuurlijk een referentie meegegeven moet worden aan de server die dan methoden kan aanroepen op de echte instantie op de client. De client is dus in feite ook server.

Schets van mijn client:

code:

public class Client: MarshalByRefObject
{
  private UserEventHandler onlineHandler;
 
  public Client(string[] parameters)
  {
    center = ...
 
    onlineHandler = new UserEventHandler(OnlineUser);
    center.OnlineUser += onlineHandler;
 
    public void OnlineUser(object sender, UserEventArgs e)
    {
      Console.WriteLine("{0} is online", e.User.Name);        
    }
  }
}

[whoami]

Ik heb dit even geprobeerd, maar dit lost het probleem niet op.

Die eventhandler zal zowiezo moeten geserializeerd worden voordat hij via het Channel kan verzonden worden, en hij zal gedeserialiseerd moeten worden als hij wordt uitgelezen ofzo.

* whoami zoekt ook nog wat verder.

Ik heb ondertussen ook ff geprobeerd om m'n object op een andere manier aan te maken op de client:

code:

ChannelServices.RegisterChannel(new HttpChannel(0));
RemotingConfiguration.RegisterWellKnownClientType(typeof(MyClass), "url");
        
_o = new MyClass();

_o.MyEvent += new MyReceiverEventHandler(functionname);

Maar hier krijg ik dezelfde fout.

[mbravenboer]

In mijn oude code gebruikte ik dit:

code:

  HTTPChannel chan = new HTTPChannel(999);
  ChannelServices.RegisterChannel(chan);
 
  center = (I...)Activator.GetObject(typeof(I....),
      "http://" + parameters[0] + ":" + parameters[1] + "/../Center");

Waarbij I... de naam van een interface was 0 en 1 uiteraard ip en poort zijn.

[ Voor 13% gewijzigd door mbravenboer op 27-09-2003 13:03 ]

[whoami]

Mja, ik doe het ook zo, behalve dan dat ik in m'n client geen Channel meer maak, maar de port die moet gebruikt worden opgeef in m'n url.

Als ik deze lijn uitcomment:

code:

_o.MyEvent += new MyReceiverEventHandler(....);

Dan krijg ik die exception niet meer. ('t Is dan ook op die regel dat die exception wordt gegooid. ).
Het aanmaken van m'n remote object is dus geen probleem.

Deze hier heeft hetzelfde probleem als ik.
Deze link leert me dat deze exceptie wel gegooid wordt in .NET v1.1, maar niet in .NET v1.0. De link die daar gepost werd blijkt echter niet te werken.

Deze link biedt misschien een uitkomst.... ff checken.

[ Voor 10% gewijzigd door whoami op 27-09-2003 13:14 ]

[gorgi_19]

whoami schreef op 27 september 2003 @ 13:13:
Deze link leert me dat deze exceptie wel gegooid wordt in .NET v1.1, maar niet in .NET v1.0. De link die daar gepost werd blijkt echter niet te werken.

quote: http://www.ingorammer.com/remotingFAQ/changes2003.html

NET Remoting - Changes for .NET 1.1 / Visual Studio 2003
With the introduction of version 1.1 of the .NET Framework, a number of Remoting-related changes have been made. Most of them are focused at increasing security of .NET applications and I therefore consider them A Good Thing. Unfortunately though, they broke a number of samples in my books (and in all the other Remoting books out there).

If you use client activated objects, events or delegates you will quite likely encounter one of the following exceptions when running on the .NET Framework 1.1:

System.Security.SecurityException.
Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.
System.Runtime.Serialization.SerializationException
Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.
To change the security level to allow passing of delegates and object references over Remoting boundaries, you have to change the so called "typeFilterLevel".

You can do this either by using a configuration file like this (for server side):

<configuration>
<system.runtime.remoting>
<channel ref="http" port="1234">
<serverProviders>
<provider ref="wsdl" />
<formatter ref="soap" typeFilterLevel="Full" />
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
<clientProviders>
<formatter ref="binary" />
</clientProviders>
</channel>
<service>
<!-- ... Add your services here ... -->
</service>
</system.runtime.remoting>
</configuration>
In this case, a matching client-side configuration file which allows the reception of events and callbacks, would look like this:

<configuration>
<system.runtime.remoting>
<channel ref="http" port="0">
<clientProviders>
<formatter ref="binary" />
</clientProviders>
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
</channel>
<client>
<!-- ... Add your classes here ... -->
</client>
</system.runtime.remoting>
</configuration>
If you prefer to setup your channels in source code, you have to use the extended constructor of the HttpChannel or TcpChannel to pass a custom IFormatterSinkProvider object:

BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;

BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();

IDictionary props = new Hashtable();
props["port"] = 1234;

HttpChannel chan = new HttpChannel(props, clientProv, provider);
ChannelServices.RegisterChannel( chan );

You can find more details about these changes and the possible type filter levels at http://www.gotdotnet.com/...1.1/default.aspx#00000153.

* gorgi_19 is in doe-lief-modus en post de content van de pagina die niet meer zou werken ..
* gorgi_19 verwacht nu eigenlijk wel dat whoami minstens een kopje thee meedrinkt met mij en lift..

[ Voor 27% gewijzigd door gorgi_19 op 27-09-2003 13:18 ]

[whoami]

Hmmm.....
Ik heb het nu als volgt:

Server:

code:

SoapServerFormatterSinkProvider prov = new SoapServerFormatterSinkProvider();
SoapClientFormatterSinkProvider cp = new SoapClientFormatterSinkProvider();
prov.TypeFilterLevel = TypeFilterLevel.Full;

IDictionary prop = new Hashtable();
prop["port"] = mijnpoortnr;

HttpChannel chan = new HttpChannel(props, cp, prov);
ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterWellKnownServiceType(.....

Ik krijg nu wel geen SecurityException meer, maar wel een SerializationException:

Kan assembly 'client' niet vinden

Ik vind op newsgroups allemaal messages die zeggen dat je naast het Serializable attribuut ook de ISerializable interface moet implementeren.
Echter, ik heb nergens het Serializable attribuut gedefinieerd.

* whoami zal dat dus maar eens gaan doen.

[ Voor 17% gewijzigd door whoami op 27-09-2003 13:50 ]

[Prozaq]

mbravenboer schreef op 27 September 2003 @ 12:00:
De client is dus in feite ook server.
[/code]

Dit is ook meteen een van de redenen waarom events icm remoting niet echt aan te raden is. De server maakt nl een verbinding terug naar de client, als de client achter een NAT router zit gaat dit dus niet werken.

[whoami]

Ik heb m'n remoted object nu het serializable attribuut meegegeven, en de ISerializable interface geimplementeerd, maar ik blijf die exceptie krijgen.

[mbravenboer]

Het heeft niet zoveel nut om je client serializable te maken: de server _moet_ een referentie naar een remote object hebben om daar een methode aan te kunnen roepen. Ik denk daarom niet dat je de oplossing moet zoeken richting zakn serializable maken.

De server moet helaas in veel situaties ook de implementatie van de client hebben. Ik ben er toen niet in geslaagd daar om heen te werken, zelfs niet via interfaces, die in feite helemaal niet gebruikt bleken te worden.

Is je client code beschikbaar voor de server?

[Anoniem: 37636]

whoami schreef op 27 september 2003 @ 13:44:
Hmmm.....
Ik heb het nu als volgt:

Server:

code:

SoapServerFormatterSinkProvider prov = new SoapServerFormatterSinkProvider();
SoapClientFormatterSinkProvider cp = new SoapClientFormatterSinkProvider();
prov.TypeFilterLevel = TypeFilterLevel.Full;

IDictionary prop = new Hashtable();
prop["port"] = mijnpoortnr;

HttpChannel chan = new HttpChannel(props, cp, prov);
ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterWellKnownServiceType(.....

Ik krijg nu wel geen SecurityException meer, maar wel een SerializationException:

[...]


Ik vind op newsgroups allemaal messages die zeggen dat je naast het Serializable attribuut ook de ISerializable interface moet implementeren.
Echter, ik heb nergens het Serializable attribuut gedefinieerd.

* whoami zal dat dus maar eens gaan doen.

De klasse waarin de eventhandler zit is niet bekend bij de server. Je zult een klasse moeten schrijven die je de server en client delen:

C#:

...
public class X : MarshalByRefObject
{
    public event MyEventHandler MyEvent;

    public void OnMyEventCallBack(object sender, MyEventArgs e)
    {
        if (MyEvent != null) MyEvent(sender, e);
    }
}
...

Vervolgens doe je op de client:

C#:

...
X blah = new X();
blah.MyEvent += new MyEventHandler(this.blah_MyEvent);
serverObj.MyEvent += new MyEventHandler(blah.OnMyEventCallBack);
...

De server kent de klasse met de eventhandler. Deze klasse die werkt als een 'tussenpersoon', zal vervolgens de event waar het om gaat zelf ook raisen, om het vervolgens mogelijk te maken voor de client om de event af te handelen.

[whoami]

mbravenboer schreef op 27 september 2003 @ 14:24:
Het heeft niet zoveel nut om je client serializable te maken: de server _moet_ een referentie naar een remote object hebben om daar een methode aan te kunnen roepen. Ik denk daarom niet dat je de oplossing moet zoeken richting zakn serializable maken.

M'n client is niet serializeerbaar, het is m'n remote object (dat op de server draait) die serializeerbaar is.

De server moet helaas in veel situaties ook de implementatie van de client hebben. Ik ben er toen niet in geslaagd daar om heen te werken, zelfs niet via interfaces, die in feite helemaal niet gebruikt bleken te worden.

Bedoel je niet dat de client een referentie naar het remoting object moet hebben?
Dat wordt verwezenlijkt door een proxy object te creeëren op de client.
(Of begrijp ik je nu verkeerd?)

Is je client code beschikbaar voor de server?

Mijn server weet niets af van m'n client, als je dat bedoeld. Juist daarom dat ik bepaalde functionaliteit mbhv delegates wil oplossen.

[whoami]

Anoniem: 37636 schreef op 27 September 2003 @ 14:25:
[...]


De klasse waarin de eventhandler zit is niet bekend bij de server. Je zult een klasse moeten schrijven die je de server en client delen:

C#:

...
public class X : MarshalByRefObject
{
    public event MyEventHandler MyEvent;

    public void OnMyEventCallBack(object sender, MyEventArgs e)
    {
        if (MyEvent != null) MyEvent(sender, e);
    }
}
...

Vervolgens doe je op de client:

C#:

...
X blah = new X();
blah.MyEvent += new MyEventHandler(this.blah_MyEvent);
serverObj.MyEvent += new MyEventHandler(blah.OnMyEventCallBack);
...

De server kent de klasse met de eventhandler. Deze klasse die werkt als een 'tussenpersoon', zal vervolgens de event waar het om gaat zelf ook raisen, om het vervolgens mogelijk te maken voor de client om de event af te handelen.

Dit gebeurt toch al door middel van dat proxy object? Of begrijp ik je verkeerd?

[mbravenboer]

whoami: Mijn server weet niets af van m'n client, als je dat bedoeld. Juist daarom dat ik bepaalde functionaliteit mbhv delegates wil oplossen.

Hehe, grapjas . Die events moeten op de een of andere manier toch bij de client terecht komen. Er gaan dus remote procedure calls de andere kant: van de server naar de client ipv de client naar de server. De server moet dus een ref hebben naar een remote object op de client.

[Anoniem: 37636]

whoami schreef op 27 September 2003 @ 14:37:
[...]


Dit gebeurt toch al door middel van dat proxy object? Of begrijp ik je verkeerd?

De server kent de klasse niet waarin je eventhandler zit. Je had ergens iets staan als:

C#:

myObj.MyEvent += new MyEventHandler(functionName);

Van welke klasse is 'functionName' een member? Is deze klasse bekend bij de server, waar de event geraised wordt? Waarschijnlijk niet, en waarschijnlijk krijg je daarom de exception waar je het over had.

Daarom moet je een klasse implementeren die bekend is bij de server en bij de client.

[whoami]

Ok.

Ik heb een class 'MyClass' die inherit van MarshalByRefObject. Instanties van die class moeten dus dmv remoting aangeroepen worden.
Die class ziet ongeveer er zo uit:

code:

public Class MyClass : MarshalByRefObject
{

  public event MyReceiver    OnReceive;

}

Ik heb een Server applicatie ServerApp, waar ik mijn remote class 'registreer':

code:

HttpChannel chan = new HttpChannel( ... );
ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterWellknownServiceType(typeof(MyClass), "blaat", WellknownObjectMode.Singleton);

Eens mijn serverapp runned, dan kan ik een client applicatie opstarten die als volgt een connectie maakt naar dat remoting object:

code:

MyClass _c;

_c = (MyClass)Activator.GetObject (.....);

_c.OnReceive += new MyReceiver(afunctionname);

[mbravenboer]

Ik begrijp niet helemaal of je er nu uit bent of niet?

whoami: Eens mijn serverapp runned, dan kan ik een client applicatie opstarten die als volgt een connectie maakt naar dat remoting object

Er wordt hier niet zomaar een connectie gemaakt: je meld je aan voor een event. De server moet nu dus voortaan jouw client kunnen aanroepen als er een event afgeleverd moet worden.

Wat jij dus zegt:

Instanties van die class moeten dus dmv remoting aangeroepen worden.

Geldt dus met name de andere kant op. De client moet dmv remoting aangeroepen vanaf de server. De server aanroep gebruik je alleen maar om je even aan te melden.

Je zou het eigenlijk eens zonder events en delegates moeten implementeren, maar zoals in Java: interfaces voor listeners. Je voelt dan precies aan wat er eigenlijk moet gebeuren.

[whoami]

mbravenboer schreef op 27 September 2003 @ 14:59:
Ik begrijp niet helemaal of je er nu uit bent of niet?

Hetgeen ik beschreven heb, is hetgeen ik nu heb.

Er wordt hier niet zomaar een connectie gemaakt: je meld je aan voor een event. De server moet nu dus voortaan jouw client kunnen aanroepen als er een event afgeleverd moet worden.

In m'n Remoting class 'MyClass' heb ik natuurlijk ook nog wel een method:

code:

public void Send(string blaat, string blat2)
{
   if( MyReicever != null )
   {
       MyReceiver(this, new ReceiverArgs(blaat, blat2));
   }
}

Die delegate wordt dus uitgevoerd als ik vanuit m'n client dit ga doen:

code:

_c.Send(...);

[Anoniem: 37636]

whoami schreef op 27 September 2003 @ 14:52:
Ok.

Ik heb een class 'MyClass' die inherit van MarshalByRefObject. Instanties van die class moeten dus dmv remoting aangeroepen worden.
Die class ziet ongeveer er zo uit:

code:

public Class MyClass : MarshalByRefObject
{

  public event MyReceiver    OnReceive;

}

Ik heb een Server applicatie ServerApp, waar ik mijn remote class 'registreer':

code:

HttpChannel chan = new HttpChannel( ... );
ChannelServices.RegisterChannel(chan);

RemotingConfiguration.RegisterWellknownServiceType(typeof(MyClass), "blaat", WellknownObjectMode.Singleton);

Eens mijn serverapp runned, dan kan ik een client applicatie opstarten die als volgt een connectie maakt naar dat remoting object:

code:

MyClass _c;

_c = (MyClass)Activator.GetObject (.....);

_c.OnReceive += new MyReceiver(afunctionname);

Zodra de server de event raised, zal 'afunctionname' in een voor de server onbekende klasse de event afvuren. Daardoor krijg je een exception.

Wanneer je echter een shared klasse hebt waarin je de event die de server raised afhandelt, is het geen probleem.
Echter, je wil als client zelf bepalen wat je doet in de eventhandler. Daarom kun je 2 dingen doen met de shared klasse:
- De client de shared klasse laten overerven. De shared klasse kan eventueel abstract zijn. In deze shared klasse raise je vervolgens niet het event, maar je roept een abstract method aan. Deze abstract method zal de client implementeren om vervolgens de event af te handelen.
- De event ook implementeren in de shared klasse, en deze raisen wanneer de event op de server geraised is. Zo kan een client op een indirecte manier de event op de server gewoon afhandelen.

Hou in de gaten dat de eventargs gemarkeerd zijn als 'Serializable'. Ze hoeven geen ISerializable te implementeren.
Verder is het _geloof ik_ ook nodig om de objecten in de eventargs MBRO te maken. Dus als de eventargs een 'User' object bevat, zal User een MBRO moeten zijn.

[whoami]

Anoniem: 37636 schreef op 27 September 2003 @ 15:03:
[...]

Hou in de gaten dat de eventargs gemarkeerd zijn als 'Serializable'. Ze hoeven geen ISerializable te implementeren.

Normaal gezien niet nee.
Het Serializable Attribuut gaat ervoor zorgen dat de public en private fields geserialiseerd worden.
Mbhv de ISerializable interface kan je het serializatie-proces gaan overriden.
Echter, ik zei dat ik zowel het serializable attribuut ging definieren en die interface implementeren nvl deze link:
klik

Verder is het _geloof ik_ ook nodig om de objecten in de eventargs MBRO te maken. Dus als de eventargs een 'User' object bevat, zal User een MBRO moeten zijn.

MBRO

[Anoniem: 37636]

MBRO?

MarshalByRefObject.

[whoami]

Anoniem: 37636 schreef op 27 September 2003 @ 15:03:
[...]


Zodra de server de event raised, zal 'afunctionname' in een voor de server onbekende klasse de event afvuren. Daardoor krijg je een exception.

Dat is toch net het hele concept wb delegates?
Dat een object een method kan uitvoeren, zonder dat hij hoeft te weten welke method dat is, en van welke class ze is.

[whoami]

Dit hier is een tutorial waarin ongeveer hetzelfde gedaan wordt als wat ik wil doen.
De auteur heeft hier ook een serverapplicatie, een server (remoted) object en een client app, precies zoals ik het heb.
In de comments lees ik van iemand die dit wil compilen in .NET 1.1 en daar ook die fout krijgt die ik kreeg, nl. de securityexception.

Ik ga mijn code (zoals ze oorspronkelijk was, dus zonder die SoapFormatterProvider etc...) later deze week eens testen (compilen) onder .NET v1.0.

[whoami]

In .NET v1.0 heb ik het voor elkaar gekregen.

Ik heb in .NET v1.0 een remote server object, dat inherit van MarshalByRefObj. Dat Server object bevat een event.

Mijn server-applicatie registreert een channel en registreert m'n server-class.

M'n client-class inherit ook van MarshalbyRefObj, registreert een channel. Ik maak daar een ref. naar m'n remote object en assign een method aan m'n event:

code:

MyServerObj obj = (MyServerObj)Activator.GetObject(....
obj.MyEvent += new MyDelegateType(....

Als ik dan later een method van m'n remote object aanroep, wordt m'n event getriggered.

Vanavond ofzo eens kijken om het in .NET v1.1 te laten werken.

[whoami]

Hmm,... nog ff een opmerking.

Als ik met een HttpChannel werk, dan werkt dat spulletje naadloos. Echter, als ik geen HttpChannel wil gebruiken, maar een TcpChannel, dan 'blokkeert' het boeltje.

[whoami]

Update:
Ik heb het in .NET 1.1 ook werkend gekregen.

De oplossing lag hem idd in die FormatterSinkProviders.
Bij het maken van het channel (zowel op de server, als op de clientkant), moet je die formatters dus meegeven:

_Server:

code:

IDictionary properties = new HashTable();
properties.Add("port", 8811);

SoapServerFormatterSinkProvider prov = new SoapServerFormatterSinkProvider();
prov.TypeFilterLevel = TypeFilterLevel.Full;

SoapClientFormatterSinkProvider clientprov = new SoapClientFormatterSinkProvider();


HttpChannel     chan;
chan = new HttpChannel(properties, clientprov, prov);
ChannelServices.RegisterChannel(chan);

_client:

code:

HttpChannel chan;

IDictionary prop = new HashTable();
prop.Add("port", 0);

SoapServerFormatterSinkProvider prov = new ...
prov.TypeFilterLevel = TypeFilterLevel.Full;

SoapClientFormatterSinkProvider cp = new ...

chan = new HttpChannel(prop, cp, prov);
ChannelServices.RegisterChannel (chan);