Récupérer le nom de l'utilisateur Windows dans la ligne de commande ?

Le
Dan
Bonjour à tous,

Est-il possible de paramétrer un raccourci vers une appli, avec, dans la
ligne de commande, le nom de l'utilisateur défini à l'ouverture de la
session Windows ?

Merci d'avance pour vos contributions !
Dan
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Jessy Sempere [MVP]
Le #6053281
Bonjour

Pourquoi le récupérer sur la ligne de commande...
Que tu le définisses avant ou après l'ouverture de ta base, le nom
de l'utilisateur de Windows sera le même ???

Il te suffit de faire sous Access :

Environ("UserName")

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" 43438f92$0$27413$
Bonjour à tous,

Est-il possible de paramétrer un raccourci vers une appli, avec, dans la
ligne de commande, le nom de l'utilisateur défini à l'ouverture de la
session Windows ?

Merci d'avance pour vos contributions !
Dan




Dan
Le #6053201
Bonjour Jessy,

L'idée est d'éviter l'obligation de saisir le nom du user, et de n'exiger
que le password (les utilisateurs tapent leur identifiant complet à tout
bout de champ...). Mais je ne veux pas mettre le user "en dur" dans la ligne
de commande, pour éviter des utilisations usurpées des bases...

En récupérant le user, on divise par 2 le poids de cette obligation...

A+ Dan
Jessy Sempere [MVP]
Le #6053181
Re,

Oui, je comprends le principe, mais comment gères tu la sécurité de
ta base ???
Si tu as mis en place une gestion par utilisateur, tu ne pourras pas
mettre un nom par défaut dans la fenêtre de login qui s'ouvre
automatiquement à l'ouverture de ta base... ;-(((

Si par contre, tu as une gestion personnalisée des tes utilisateurs
avec par exemple un formulaire de login personnalisé, une table
avec les mots de passe, ... là tu pourras faire ce que tu souhaites
mais la sécurité sera moins efficace que l'autre.

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" 43439843$0$17222$
Bonjour Jessy,

L'idée est d'éviter l'obligation de saisir le nom du user, et de n'exiger
que le password (les utilisateurs tapent leur identifiant complet à tout
bout de champ...). Mais je ne veux pas mettre le user "en dur" dans la
ligne

de commande, pour éviter des utilisations usurpées des bases...

En récupérant le user, on divise par 2 le poids de cette obligation...

A+ Dan





Dan
Le #6053121
Merci Jessy de t'intéresser à mon problème,

Tu dis :

"Si tu as mis en place une gestion par utilisateur, tu ne pourras pas
mettre un nom par défaut dans la fenêtre de login qui s'ouvre
automatiquement à l'ouverture de ta base... ;-((("

C'était justement le sens de ma question : le système connaît l'utilisateur
qui a ouvert la session Wiondows. Le plan de sécu du réseau et celui
d'Access utilisant les mêmes identifiants, il "suffirait" de pouvoir le
récupérer dans la ligne de commande...

A l'aide d'un fichier.ini allant lire les variables d'environnement,
peut-être ?

A+ Dan
Jessy Sempere [MVP]
Le #6053111
Re,

C'était justement le sens de ma question : le système connaît
l'utilisateur

qui a ouvert la session Wiondows. Le plan de sécu du réseau et celui
d'Access utilisant les mêmes identifiants, il "suffirait" de pouvoir le
récupérer dans la ligne de commande...


Oui, le système connaît l'utilisateur qui a ouvert la session Windows mais
access n'utilise pas les même identifiant...
En fait ma question, c'était comment as-tu mis définis la sécurité de ta
base,
as-tu fait toi même une sécurité par utilisateur ou as-tu utiliser la
gestion
des utilisateurs propre à Access qui se définit avec le menu :
"Outil" - "Sécurité" - "Gestion des utilisateurs et des groupes..."

--
@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" 43439f05$0$1715$
Merci Jessy de t'intéresser à mon problème,

Tu dis :

"Si tu as mis en place une gestion par utilisateur, tu ne pourras pas
mettre un nom par défaut dans la fenêtre de login qui s'ouvre
automatiquement à l'ouverture de ta base... ;-((("

C'était justement le sens de ma question : le système connaît
l'utilisateur

qui a ouvert la session Wiondows. Le plan de sécu du réseau et celui
d'Access utilisant les mêmes identifiants, il "suffirait" de pouvoir le
récupérer dans la ligne de commande...

A l'aide d'un fichier.ini allant lire les variables d'environnement,
peut-être ?

A+ Dan





Dan
Le #6053101
J'utilise un groupe de travail "reso.mdw" commun à toutes mes applis...

J'ai aussi mis au point une appli baptisée "Lanceur d'applications", dans
laquelle je répertorie les Users, les applis (avec leur chemin et la version
en cours), les associations User/Applis, et les PC.

Ce Lanceur me permet de proposer les applis auxquels les users peuvent
accéder, de mettre à jour la version Runtime sur les PC, et de lancer
l'appli demandée sans exiger une nouvelle identification...
Le Lanceur se ferme à chaque lancement pour éviter les usurpations...

Dans chaque appli, l'utilisateur a aussi la possibilité de retourner au
Lanceur (ce qui ferme l'appli en cours).

Tout ça réduit le nombre d'identifications nécessaires, mais ne concerne que
le parc applicatif Access. Or, en plus des progiciels (dans lesquels il faut
s'identifier là aussi !), nous allons vers un projet de portail Intranet,
qui exigera sans doute une identification supplémentaire...

On ne fera bientôt plus que ça : s'identifier ! C'est pourquoi j'essaie de
réduire cette obligation...

A+ Dan
Jessy Sempere [MVP]
Le #6053091
Re,

Ouaa !!!
A lire ce que tu décris, ça me paraît déjà très bien... ;-))
Bon si je résume, lorsqu'un utilisateur veut se connecter à l'une
de ces applications, il passe par ton lanceur ???
Ensuite depuis ce lanceur il sélectionne l'application qu'il veut
lancer et c'est là qu'elle lui redemande son nom et son mot de passe ???

Si c'est bien ça, il te suffit de modifier ta ligne de code te permettant
de lancer l'appli voulue par un truc du genre :

dim strAppli as string '** chemin complet de l'appli
Shell("MSACCESS.EXE """ & strAppli & """ /user """ &
Environ("username"),vbMaximizedFocus

Voir à vérifier la synthaxe pour les guillemets ou autre.

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" 4343a515$0$5380$
J'utilise un groupe de travail "reso.mdw" commun à toutes mes applis...

J'ai aussi mis au point une appli baptisée "Lanceur d'applications", dans
laquelle je répertorie les Users, les applis (avec leur chemin et la
version

en cours), les associations User/Applis, et les PC.

Ce Lanceur me permet de proposer les applis auxquels les users peuvent
accéder, de mettre à jour la version Runtime sur les PC, et de lancer
l'appli demandée sans exiger une nouvelle identification...
Le Lanceur se ferme à chaque lancement pour éviter les usurpations...

Dans chaque appli, l'utilisateur a aussi la possibilité de retourner au
Lanceur (ce qui ferme l'appli en cours).

Tout ça réduit le nombre d'identifications nécessaires, mais ne concerne
que

le parc applicatif Access. Or, en plus des progiciels (dans lesquels il
faut

s'identifier là aussi !), nous allons vers un projet de portail Intranet,
qui exigera sans doute une identification supplémentaire...

On ne fera bientôt plus que ça : s'identifier ! C'est pourquoi j'essaie de
réduire cette obligation...

A+ Dan




Dan
Le #6052961
C'est presque ça...

" Ensuite depuis ce lanceur il sélectionne l'application qu'il veut
lancer et c'est là qu'elle lui redemande son nom et son mot de passe ???"

Non, justement, le Lanceur connait l'utilisateur et ne lui demande rien...
La syntaxe que tu as la gentillesse de me donner, je l'ai trouvée dans ce
newsgroup il y a quelques années déjà... C'est peut-être toi qui me l'avais
transmise !

Ce Lanceur préfigure un portail Intranet, puisqu'on y trouve des accès vers
à peu près tout ce qu'on peut trouver sur un réseau (documents de tous
formats, applis en tous genre, URL, etc ...)
C'est un outil vital pour la collectivité, mais il a une pérennité
discutable en l'état (pas vraiment full-web tout ça !!!)...

Le plus gênant, c'est cette étape d'identification, redondante avec celle de
Windows et des progiciels utilisés, dont la ligne de commande n'est pas
toujours paramétrable...

Dan
Jessy Sempere [MVP]
Le #6052941
Bon là je suis perdu... ;-))
C'est quoi le problème exactement ?
Que veux-tu faire exactement, comment, depuis où,
pour lancer quoi ?

@+
Jessy Sempere - Access MVP

------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" 4343bd10$0$1738$
C'est presque ça...

" Ensuite depuis ce lanceur il sélectionne l'application qu'il veut
lancer et c'est là qu'elle lui redemande son nom et son mot de passe ???"

Non, justement, le Lanceur connait l'utilisateur et ne lui demande rien...
La syntaxe que tu as la gentillesse de me donner, je l'ai trouvée dans ce
newsgroup il y a quelques années déjà... C'est peut-être toi qui me
l'avais

transmise !

Ce Lanceur préfigure un portail Intranet, puisqu'on y trouve des accès
vers

à peu près tout ce qu'on peut trouver sur un réseau (documents de tous
formats, applis en tous genre, URL, etc ...)
C'est un outil vital pour la collectivité, mais il a une pérennité
discutable en l'état (pas vraiment full-web tout ça !!!)...

Le plus gênant, c'est cette étape d'identification, redondante avec celle
de

Windows et des progiciels utilisés, dont la ligne de commande n'est pas
toujours paramétrable...

Dan




Dan
Le #6052931
Je voulais juste savoir si quelqu'un avait déjà réussi à récupérer le nom de
l'utilisateur Windows en paramètre de la ligne de commande...

Dan
Poster une réponse
Anonyme