Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[C#]Problème avec la sécurité et .NET 2 REMOTING

4 réponses
Avatar
Nico
Bonjour

J'ai un problème de sécurité avec .NET 2 et le remoting.

Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance une
exception lié à la sécurité.

J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.

Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.

Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.

Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier définit
dans le fichier .dll que le serveur et le client référence :


Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="Infrastructure"/>

La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>

Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>

La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack, System.Runtime.Remoting.Messaging.IMessage,
System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---

Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)

Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:\Documents and
Settings\a.UNI
-24064D\Mes documents\Visual Studio
2005\Projects\mapping\remoting_client\Program.cs:ligne
28

Quelqu'un a une idée d'un truc que j'aurai mal fait ?

Merci d'avance

4 réponses

Avatar
Paul Bacelar
Il y a aussi les droits de l'utilisateur ayant lancé l'application à prendre
en compte.
--
Paul Bacelar
MVP VC++

"Nico" wrote in message
news:
Bonjour

J'ai un problème de sécurité avec .NET 2 et le remoting.

Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.

J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.

Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.

Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.

Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :


Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>

La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>

Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>

La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---

Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)

Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28

Quelqu'un a une idée d'un truc que j'aurai mal fait ?

Merci d'avance



Avatar
Nico
Je lance l'application avec les droits administrateurs. C'est ma machine de
développement.

Vraiment je ne vois pas comment résoudre ce problème. J'ai essayé de
désactiver temporairement la sécurité avec caspol mais même en lé
désactivant je n'arrivais pas à éxecuter le logiciel.

Personne ne sait comment résoudre ce problème ? Un MVP serait le bienvenu :)


"Paul Bacelar" a écrit dans le message
de news:
Il y a aussi les droits de l'utilisateur ayant lancé l'application à
prendre en compte.
--
Paul Bacelar
MVP VC++

"Nico" wrote in message
news:
Bonjour

J'ai un problème de sécurité avec .NET 2 et le remoting.

Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.

J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.

Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.

Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.

Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:


Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>

La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>

Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>

La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---

Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)

Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28

Quelqu'un a une idée d'un truc que j'aurai mal fait ?

Merci d'avance







Avatar
Simon Mourier [SoftFluent]
Jetez peut-être un coup d'oeil sur ces threads

http://dotnet247.com/247reference/msgs/53/268056.aspx
http://www.thinktecture.com/Resources/RemotingFAQ/Changes2003.html

Simon.
www.softfluent.com


"Nico" a écrit dans le message de news:

Bonjour

J'ai un problème de sécurité avec .NET 2 et le remoting.

Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.

J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.

Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.

Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit de
"faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine mais
... ce n'est pas le cas ... j'obtiens toujours la même exception malgré
d'autres tests du même type dans le logiciel de configuration du .NET 2.

Ci-dessous l'exception complète qui est lancée par le client .NET REMOTING
lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet métier
définit dans le fichier .dll que le serveur et le client référence :


Exception non gérée : System.Runtime.Serialization.SerializationException:
En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>

La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>

Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>

La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef,
System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---

Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)

Exception rethrown at [0]:
à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28

Quelqu'un a une idée d'un truc que j'aurai mal fait ?

Merci d'avance



Avatar
Nico
Thanks

J'avais entre temps trouvé la solution qui était bien de rajouter
typeFilterLevel="Full".

@ +



http://dotnet247.com/247reference/msgs/53/268056.aspx
http://www.thinktecture.com/Resources/RemotingFAQ/Changes2003.html

Simon.
www.softfluent.com


"Nico" a écrit dans le message de news:

Bonjour

J'ai un problème de sécurité avec .NET 2 et le remoting.

Lorsque j'essaye d'envoyer un objet du client vers le serveur cela lance
une exception lié à la sécurité.

J'essaye donc depuis de donner les privilèges complets à mon application
cliente mais sans résultat.

Voici ce que j'ai fais :
-création d'un nom fort et ajout de la directive [assembly:
AssemblyKeyFile("protec.snk")] avec l'adresse de ma clef que j'ai généré
avec sn -k protec.snk au client et au serveur .NET REMOTING ainsi qu'au
fichier .dll métier.

Après cela je suis allé dans Outils d'administration->Configuration
Microsoft .NET Framework 2.0 afin d'allouer à mon application .NET 2
d'avantages de droits.
Ensuite je clic sur "Stratégie de sécurité du runtime" puis "Augmenter le
niveau de confiance d'un assembly".
Ensuite je choisis l'adresse du .exe du client .NET REMOTING et choisit
de "faire confiance à toute les assemblys avec la même clef publique
d'assembly". A partir de là, je suppose que le fichier .dll métier, le
serveur et le client .NET REMOTING.
Ensuite je choisis de faire une confiance totale à cette assembly.
Là je m'attend à ceux que le serveur, le client et le fichier .dll qui
partage la même clef bénéficieront des droits complets sur ma machine
mais ... ce n'est pas le cas ... j'obtiens toujours la même exception
malgré d'autres tests du même type dans le logiciel de configuration du
.NET 2.

Ci-dessous l'exception complète qui est lancée par le client .NET
REMOTING lorsque j'essaye d'envoyer au serveur .NET REMOTING un objet
métier définit dans le fichier .dll que le serveur et le client référence
:


Exception non gérée :
System.Runtime.Serialization.SerializationException: En raison de re
strictions de sécurité, le type System.Runtime.Remoting.ObjRef est
inaccessible. ---> Syst
em.Security.SecurityException: Échec de la demande.
à
System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(Runti
meType type)
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
L'action qui a échoué était :
Demand
Le type de la première autorisation qui a échoué était :
System.Security.Permissions.SecurityPermission
La première autorisation qui a échoué était :
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>

La demande était pour :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="Infrastructure"/>
</PermissionSet>

Les seules autorisations permises étaient :
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.SecurityPermission,
mscorlib, Version=2.0.
0.0, Culture=neutral, PublicKeyToken·7a5c561934e089"
version="1"
Flags="SerializationFormatter"/>
</PermissionSet>

La méthode qui a causé l'échec était :
System.Runtime.Remoting.Channels.ServerProcessing
ProcessMessage(System.Runtime.Remoting.C
hannels.IServerChannelSinkStack,
System.Runtime.Remoting.Messaging.IMessage, System.Runtim
e.Remoting.Channels.ITransportHeaders, System.IO.Stream,
System.Runtime.Remoting.Messaging
.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders
ByRef, System.IO.Strea
m ByRef)
--- Fin de la trace de la pile d'exception interne ---

Server stack trace:
à
System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type
type)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord
p
r)
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord
pr)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryObjectWithMapTyped record)
à
System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(
BinaryHeaderEnum binaryHeaderEnum)
à System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
à
System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler
handler, __BinaryParser serParser, Boolean fCheck, Boolean
isCrossAppDomain, IMethodCallM
essage methodCallMessage)
à
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream
ser
ializationStream, HeaderHandler handler, Boolean fCheck, Boolean
isCrossAppDomain, IMethod
CallMessage methodCallMessage)
à
System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String
o
bjectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel
securityLevel)
à
System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChan
nelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders
requestHeaders, Stream requ
estStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStre
am)

Exception rethrown at [0]:
à
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessa
ge retMsg)
à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData&
msgData, Int32 t
ype)
à ng.mapping.IDBManager.saveOrUpdateBusinessObject(Object o)
à remoting_client.Program.Main(String[] args) dans C:Documents and
Settingsa.UNI
-24064DMes documentsVisual Studio
2005Projectsmappingremoting_clientProgram.cs:ligne
28

Quelqu'un a une idée d'un truc que j'aurai mal fait ?

Merci d'avance