Bonjour,
Je rencontre un problème sur une application que j'ai développé et installé
chez un prospect en VB .NET.
Dans cette application, pour un peu de sécurité et éviter que mes clients ne
se refile le produit, j'ai mis en place un système de vérifications de
clésd'authenticité que je crée et modifie dans la base de registre
(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
entendu, je me suis loggé en administreur pour pouvoir donner à cet
utilisateur un accès en contrôle total sur les ruches de la base de registre
que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
contrôle total sur le répertoire d'installation de mon application.
Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
en droits d'administration réseau... là je sèche.
Si quelqu'un a déjà rencontré un problème similaire...
Merci
---------------------------------------------------------------------------------
Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour,
Je rencontre un problème sur une application que j'ai développé et installé
chez un prospect en VB .NET.
Dans cette application, pour un peu de sécurité et éviter que mes clients ne
se refile le produit, j'ai mis en place un système de vérifications de
clésd'authenticité que je crée et modifie dans la base de registre
(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
entendu, je me suis loggé en administreur pour pouvoir donner à cet
utilisateur un accès en contrôle total sur les ruches de la base de registre
que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
contrôle total sur le répertoire d'installation de mon application.
Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
en droits d'administration réseau... là je sèche.
Si quelqu'un a déjà rencontré un problème similaire...
Merci
---------------------------------------------------------------------------------
Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour,
Je rencontre un problème sur une application que j'ai développé et installé
chez un prospect en VB .NET.
Dans cette application, pour un peu de sécurité et éviter que mes clients ne
se refile le produit, j'ai mis en place un système de vérifications de
clésd'authenticité que je crée et modifie dans la base de registre
(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
entendu, je me suis loggé en administreur pour pouvoir donner à cet
utilisateur un accès en contrôle total sur les ruches de la base de registre
que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
contrôle total sur le répertoire d'installation de mon application.
Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
en droits d'administration réseau... là je sèche.
Si quelqu'un a déjà rencontré un problème similaire...
Merci
---------------------------------------------------------------------------------
Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour,
Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
sécurité impérative
Je vous invite a faire une recherche sur ce type de sécurité. Cette
solution pourra peut être répondre à vos attentes.
Petit exemple de code à placer dans le constructeur
##########################################################
AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")
Try
Permission.Demand()
Catch se As System.Security.SecurityException
MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
programme (Veuillez contacter l'administrateur)")
End
End Try
###########################################################
Brèves explications :
"AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
Cette partie associe l'utilisateur courant à l'application
" Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")"
Nous créons une permission validant uniquement le rôle
BUILTINAdministrators (Je préconise de créer un rôle spécifique à
votre application et d'y mettre les utilisateurs autorisés)
Dans le cas présent j'ai mis nothing pour ne pas donner une permission
à un utilisateur spécifique dans le groupe Administrators mais à tous
les utilisateurs
Permission.Demand()
Comme vous pouvez vous en douter, un test est effectué pour savoir si
l'utilisateur courant fait partie du groupe BUILTINAdministrators
dans notre exemple
J'espère que cela vous aidera
Cordialement,
Mathieu Francesch
On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
wrote:
>Bonjour,
>
>Je rencontre un problème sur une application que j'ai développé et installé
>chez un prospect en VB .NET.
>Dans cette application, pour un peu de sécurité et éviter que mes clients ne
>se refile le produit, j'ai mis en place un système de vérifications de
>clésd'authenticité que je crée et modifie dans la base de registre
>(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
>Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
>de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
>entendu, je me suis loggé en administreur pour pouvoir donner à cet
>utilisateur un accès en contrôle total sur les ruches de la base de registre
>que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
>contrôle total sur le répertoire d'installation de mon application.
>
>Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
>en droits d'administration réseau... là je sèche.
>
>Si quelqu'un a déjà rencontré un problème similaire...
>
>Merci
>
>---------------------------------------------------------------------------------
>Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour,
Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
sécurité impérative
Je vous invite a faire une recherche sur ce type de sécurité. Cette
solution pourra peut être répondre à vos attentes.
Petit exemple de code à placer dans le constructeur
##########################################################
AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")
Try
Permission.Demand()
Catch se As System.Security.SecurityException
MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
programme (Veuillez contacter l'administrateur)")
End
End Try
###########################################################
Brèves explications :
"AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
Cette partie associe l'utilisateur courant à l'application
" Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")"
Nous créons une permission validant uniquement le rôle
BUILTINAdministrators (Je préconise de créer un rôle spécifique à
votre application et d'y mettre les utilisateurs autorisés)
Dans le cas présent j'ai mis nothing pour ne pas donner une permission
à un utilisateur spécifique dans le groupe Administrators mais à tous
les utilisateurs
Permission.Demand()
Comme vous pouvez vous en douter, un test est effectué pour savoir si
l'utilisateur courant fait partie du groupe BUILTINAdministrators
dans notre exemple
J'espère que cela vous aidera
Cordialement,
Mathieu Francesch
On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
Maraudeur@discussions.microsoft.com> wrote:
>Bonjour,
>
>Je rencontre un problème sur une application que j'ai développé et installé
>chez un prospect en VB .NET.
>Dans cette application, pour un peu de sécurité et éviter que mes clients ne
>se refile le produit, j'ai mis en place un système de vérifications de
>clésd'authenticité que je crée et modifie dans la base de registre
>(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
>Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
>de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
>entendu, je me suis loggé en administreur pour pouvoir donner à cet
>utilisateur un accès en contrôle total sur les ruches de la base de registre
>que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
>contrôle total sur le répertoire d'installation de mon application.
>
>Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
>en droits d'administration réseau... là je sèche.
>
>Si quelqu'un a déjà rencontré un problème similaire...
>
>Merci
>
>---------------------------------------------------------------------------------
>Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour,
Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
sécurité impérative
Je vous invite a faire une recherche sur ce type de sécurité. Cette
solution pourra peut être répondre à vos attentes.
Petit exemple de code à placer dans le constructeur
##########################################################
AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")
Try
Permission.Demand()
Catch se As System.Security.SecurityException
MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
programme (Veuillez contacter l'administrateur)")
End
End Try
###########################################################
Brèves explications :
"AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
Cette partie associe l'utilisateur courant à l'application
" Dim Permission As New
System.Security.Permissions.PrincipalPermission(Nothing,
"BUILTINAdministrators")"
Nous créons une permission validant uniquement le rôle
BUILTINAdministrators (Je préconise de créer un rôle spécifique à
votre application et d'y mettre les utilisateurs autorisés)
Dans le cas présent j'ai mis nothing pour ne pas donner une permission
à un utilisateur spécifique dans le groupe Administrators mais à tous
les utilisateurs
Permission.Demand()
Comme vous pouvez vous en douter, un test est effectué pour savoir si
l'utilisateur courant fait partie du groupe BUILTINAdministrators
dans notre exemple
J'espère que cela vous aidera
Cordialement,
Mathieu Francesch
On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
wrote:
>Bonjour,
>
>Je rencontre un problème sur une application que j'ai développé et installé
>chez un prospect en VB .NET.
>Dans cette application, pour un peu de sécurité et éviter que mes clients ne
>se refile le produit, j'ai mis en place un système de vérifications de
>clésd'authenticité que je crée et modifie dans la base de registre
>(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
>Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
>de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
>entendu, je me suis loggé en administreur pour pouvoir donner à cet
>utilisateur un accès en contrôle total sur les ruches de la base de registre
>que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
>contrôle total sur le répertoire d'installation de mon application.
>
>Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
>en droits d'administration réseau... là je sèche.
>
>Si quelqu'un a déjà rencontré un problème similaire...
>
>Merci
>
>---------------------------------------------------------------------------------
>Pourquoi faire simple quand on peut faire compliqué?????That is the question
Bonjour MAtthieu, tout d'abord, merci pour cette réponse très intéressante...
Toutefois, je ne suis pas certain qu'elle corresponde au problème que
j'essaie d'exposer, à moins que je ne l'ai pas comprise.
En effet si j'ai bien compris,cette solution propose de créer un compte
utilisateur de type administrator (ou hérité) spécifique à l'application (que
l'on pourrait appeler pour l'occasion "Application X", qui serait testé au
lancement de l'application pour s'assurer que c'est bien le bon utilisateur
qui ouvre l'application.
Mon problème est autre : l'administrateur du réseau sur lequel je dois
installer mon application refuse que l'utilisateur final de celle-ci voit ses
droits de simple utilisateur restreint(et ils le sont bien) changer pour
devenir administrateur, même local à sa machine, pour des raisons de
politique interne.
Or le problème c'est que pour le moment, je n'ai pas trouvé d'autre solution
pour faire fonctionner l'application qu'en étant administrateur local. J'ai
d'ailleurs également rencontré ce même problème sous environnement TSE,
pourlequel je n'ai pu faire fonctionner mon application qu'avec un user TSE
qui soit administrateur local de sa propre machine.
Ma question a pour objet de savoir si une application en VB .NET doit avoir
quelques pré-requis dans sa conception pour pouvoir fonctionner pour
n'importe quel utilisateur et pas seulement pour un administrateur local,
sachant que j'utilise la base de registre, ODBC, ADO 2.7, ainsi que deux dll
persos, entre autres...
Voici d'ailleurs la liste des références que j'ai affecté à mon projet :
ADODB (v2.7)
ASD100Lib (dll Sage)
COnnectLib(dll perso d'ouverture/fermeture connexions odbc)
JRO
prolic(dll perso de fonctions diverses)
Prologic.Windows.Forms (version perso)
stdole
System
System.Data
System.Drawing
System.Windows.Forms
System.XML
Pensez-vous que je dois attribuer un contrôle total sur C:Windowssystem
32, sachant que msjro.dll y est installé au setup de mon application?
Merci de votre aide, et désolé si j'ai mal compris votre réponse.
Cordialement,
Valérian
"Mathieu Francesch" a écrit :
> Bonjour,
>
> Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
> sécurité impérative
>
> Je vous invite a faire une recherche sur ce type de sécurité. Cette
> solution pourra peut être répondre à vos attentes.
>
> Petit exemple de code à placer dans le constructeur
>
>
> ##########################################################
>
>
> AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
> Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")
> Try
> Permission.Demand()
> Catch se As System.Security.SecurityException
> MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
> programme (Veuillez contacter l'administrateur)")
> End
> End Try
>
> ###########################################################
>
> Brèves explications :
>
> "AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
>
> Cette partie associe l'utilisateur courant à l'application
>
>
> " Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")"
>
> Nous créons une permission validant uniquement le rôle
> BUILTINAdministrators (Je préconise de créer un rôle spécifique à
> votre application et d'y mettre les utilisateurs autorisés)
>
> Dans le cas présent j'ai mis nothing pour ne pas donner une permission
> à un utilisateur spécifique dans le groupe Administrators mais à tous
> les utilisateurs
>
> Permission.Demand()
>
> Comme vous pouvez vous en douter, un test est effectué pour savoir si
> l'utilisateur courant fait partie du groupe BUILTINAdministrators
> dans notre exemple
>
>
> J'espère que cela vous aidera
>
> Cordialement,
>
> Mathieu Francesch
>
>
>
>
> On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
> wrote:
>
> >Bonjour,
> >
> >Je rencontre un problème sur une application que j'ai développé et installé
> >chez un prospect en VB .NET.
> >Dans cette application, pour un peu de sécurité et éviter que mes clients ne
> >se refile le produit, j'ai mis en place un système de vérifications de
> >clésd'authenticité que je crée et modifie dans la base de registre
> >(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
> >Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
> >de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
> >entendu, je me suis loggé en administreur pour pouvoir donner à cet
> >utilisateur un accès en contrôle total sur les ruches de la base de registre
> >que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
> >contrôle total sur le répertoire d'installation de mon application.
> >
> >Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
> >en droits d'administration réseau... là je sèche.
> >
> >Si quelqu'un a déjà rencontré un problème similaire...
> >
> >Merci
> >
> >---------------------------------------------------------------------------------
> >Pourquoi faire simple quand on peut faire compliqué?????That is the question
>
Bonjour MAtthieu, tout d'abord, merci pour cette réponse très intéressante...
Toutefois, je ne suis pas certain qu'elle corresponde au problème que
j'essaie d'exposer, à moins que je ne l'ai pas comprise.
En effet si j'ai bien compris,cette solution propose de créer un compte
utilisateur de type administrator (ou hérité) spécifique à l'application (que
l'on pourrait appeler pour l'occasion "Application X", qui serait testé au
lancement de l'application pour s'assurer que c'est bien le bon utilisateur
qui ouvre l'application.
Mon problème est autre : l'administrateur du réseau sur lequel je dois
installer mon application refuse que l'utilisateur final de celle-ci voit ses
droits de simple utilisateur restreint(et ils le sont bien) changer pour
devenir administrateur, même local à sa machine, pour des raisons de
politique interne.
Or le problème c'est que pour le moment, je n'ai pas trouvé d'autre solution
pour faire fonctionner l'application qu'en étant administrateur local. J'ai
d'ailleurs également rencontré ce même problème sous environnement TSE,
pourlequel je n'ai pu faire fonctionner mon application qu'avec un user TSE
qui soit administrateur local de sa propre machine.
Ma question a pour objet de savoir si une application en VB .NET doit avoir
quelques pré-requis dans sa conception pour pouvoir fonctionner pour
n'importe quel utilisateur et pas seulement pour un administrateur local,
sachant que j'utilise la base de registre, ODBC, ADO 2.7, ainsi que deux dll
persos, entre autres...
Voici d'ailleurs la liste des références que j'ai affecté à mon projet :
ADODB (v2.7)
ASD100Lib (dll Sage)
COnnectLib(dll perso d'ouverture/fermeture connexions odbc)
JRO
prolic(dll perso de fonctions diverses)
Prologic.Windows.Forms (version perso)
stdole
System
System.Data
System.Drawing
System.Windows.Forms
System.XML
Pensez-vous que je dois attribuer un contrôle total sur C:Windowssystem
32, sachant que msjro.dll y est installé au setup de mon application?
Merci de votre aide, et désolé si j'ai mal compris votre réponse.
Cordialement,
Valérian
"Mathieu Francesch" a écrit :
> Bonjour,
>
> Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
> sécurité impérative
>
> Je vous invite a faire une recherche sur ce type de sécurité. Cette
> solution pourra peut être répondre à vos attentes.
>
> Petit exemple de code à placer dans le constructeur
>
>
> ##########################################################
>
>
> AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
> Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")
> Try
> Permission.Demand()
> Catch se As System.Security.SecurityException
> MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
> programme (Veuillez contacter l'administrateur)")
> End
> End Try
>
> ###########################################################
>
> Brèves explications :
>
> "AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
>
> Cette partie associe l'utilisateur courant à l'application
>
>
> " Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")"
>
> Nous créons une permission validant uniquement le rôle
> BUILTINAdministrators (Je préconise de créer un rôle spécifique à
> votre application et d'y mettre les utilisateurs autorisés)
>
> Dans le cas présent j'ai mis nothing pour ne pas donner une permission
> à un utilisateur spécifique dans le groupe Administrators mais à tous
> les utilisateurs
>
> Permission.Demand()
>
> Comme vous pouvez vous en douter, un test est effectué pour savoir si
> l'utilisateur courant fait partie du groupe BUILTINAdministrators
> dans notre exemple
>
>
> J'espère que cela vous aidera
>
> Cordialement,
>
> Mathieu Francesch
>
>
>
>
> On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
> Maraudeur@discussions.microsoft.com> wrote:
>
> >Bonjour,
> >
> >Je rencontre un problème sur une application que j'ai développé et installé
> >chez un prospect en VB .NET.
> >Dans cette application, pour un peu de sécurité et éviter que mes clients ne
> >se refile le produit, j'ai mis en place un système de vérifications de
> >clésd'authenticité que je crée et modifie dans la base de registre
> >(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
> >Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
> >de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
> >entendu, je me suis loggé en administreur pour pouvoir donner à cet
> >utilisateur un accès en contrôle total sur les ruches de la base de registre
> >que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
> >contrôle total sur le répertoire d'installation de mon application.
> >
> >Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
> >en droits d'administration réseau... là je sèche.
> >
> >Si quelqu'un a déjà rencontré un problème similaire...
> >
> >Merci
> >
> >---------------------------------------------------------------------------------
> >Pourquoi faire simple quand on peut faire compliqué?????That is the question
>
Bonjour MAtthieu, tout d'abord, merci pour cette réponse très intéressante...
Toutefois, je ne suis pas certain qu'elle corresponde au problème que
j'essaie d'exposer, à moins que je ne l'ai pas comprise.
En effet si j'ai bien compris,cette solution propose de créer un compte
utilisateur de type administrator (ou hérité) spécifique à l'application (que
l'on pourrait appeler pour l'occasion "Application X", qui serait testé au
lancement de l'application pour s'assurer que c'est bien le bon utilisateur
qui ouvre l'application.
Mon problème est autre : l'administrateur du réseau sur lequel je dois
installer mon application refuse que l'utilisateur final de celle-ci voit ses
droits de simple utilisateur restreint(et ils le sont bien) changer pour
devenir administrateur, même local à sa machine, pour des raisons de
politique interne.
Or le problème c'est que pour le moment, je n'ai pas trouvé d'autre solution
pour faire fonctionner l'application qu'en étant administrateur local. J'ai
d'ailleurs également rencontré ce même problème sous environnement TSE,
pourlequel je n'ai pu faire fonctionner mon application qu'avec un user TSE
qui soit administrateur local de sa propre machine.
Ma question a pour objet de savoir si une application en VB .NET doit avoir
quelques pré-requis dans sa conception pour pouvoir fonctionner pour
n'importe quel utilisateur et pas seulement pour un administrateur local,
sachant que j'utilise la base de registre, ODBC, ADO 2.7, ainsi que deux dll
persos, entre autres...
Voici d'ailleurs la liste des références que j'ai affecté à mon projet :
ADODB (v2.7)
ASD100Lib (dll Sage)
COnnectLib(dll perso d'ouverture/fermeture connexions odbc)
JRO
prolic(dll perso de fonctions diverses)
Prologic.Windows.Forms (version perso)
stdole
System
System.Data
System.Drawing
System.Windows.Forms
System.XML
Pensez-vous que je dois attribuer un contrôle total sur C:Windowssystem
32, sachant que msjro.dll y est installé au setup de mon application?
Merci de votre aide, et désolé si j'ai mal compris votre réponse.
Cordialement,
Valérian
"Mathieu Francesch" a écrit :
> Bonjour,
>
> Je ne sais pas si vous vous êtes déjà orienté vers cette solution : La
> sécurité impérative
>
> Je vous invite a faire une recherche sur ce type de sécurité. Cette
> solution pourra peut être répondre à vos attentes.
>
> Petit exemple de code à placer dans le constructeur
>
>
> ##########################################################
>
>
> AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)
> Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")
> Try
> Permission.Demand()
> Catch se As System.Security.SecurityException
> MessageBox.Show("Vous n'avez pas l'autorisation d'utiliser ce
> programme (Veuillez contacter l'administrateur)")
> End
> End Try
>
> ###########################################################
>
> Brèves explications :
>
> "AppDomain.CurrentDomain.SetPrincipalPolicy(Security.Principal.PrincipalPolicy.WindowsPrincipal)"
>
> Cette partie associe l'utilisateur courant à l'application
>
>
> " Dim Permission As New
> System.Security.Permissions.PrincipalPermission(Nothing,
> "BUILTINAdministrators")"
>
> Nous créons une permission validant uniquement le rôle
> BUILTINAdministrators (Je préconise de créer un rôle spécifique à
> votre application et d'y mettre les utilisateurs autorisés)
>
> Dans le cas présent j'ai mis nothing pour ne pas donner une permission
> à un utilisateur spécifique dans le groupe Administrators mais à tous
> les utilisateurs
>
> Permission.Demand()
>
> Comme vous pouvez vous en douter, un test est effectué pour savoir si
> l'utilisateur courant fait partie du groupe BUILTINAdministrators
> dans notre exemple
>
>
> J'espère que cela vous aidera
>
> Cordialement,
>
> Mathieu Francesch
>
>
>
>
> On Fri, 21 Jul 2006 07:51:02 -0700, Le Maraudeur <Le
> wrote:
>
> >Bonjour,
> >
> >Je rencontre un problème sur une application que j'ai développé et installé
> >chez un prospect en VB .NET.
> >Dans cette application, pour un peu de sécurité et éviter que mes clients ne
> >se refile le produit, j'ai mis en place un système de vérifications de
> >clésd'authenticité que je crée et modifie dans la base de registre
> >(HKEYLOCALMACHINE et HKEYCURRENTUSER pour faire court).
> >Tout ceci fonctionne très bien dès lors que l'utilisateur est administrateur
> >de son poste. Mais dès qu'il ne l'est plus, ça ne fonctionne plus. Bien
> >entendu, je me suis loggé en administreur pour pouvoir donner à cet
> >utilisateur un accès en contrôle total sur les ruches de la base de registre
> >que j'utilise, mais sans succès. De la même manière, l'utilisateur dispose du
> >contrôle total sur le répertoire d'installation de mon application.
> >
> >Je ne vois pas d'autre truc à chercher et je ne m'y connais pas suffisamment
> >en droits d'administration réseau... là je sèche.
> >
> >Si quelqu'un a déjà rencontré un problème similaire...
> >
> >Merci
> >
> >---------------------------------------------------------------------------------
> >Pourquoi faire simple quand on peut faire compliqué?????That is the question
>