Récupérer le nom de l'utilisateur Windows dans la ligne de commande ?
15 réponses
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 ?
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" a écrit dans le message news: 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
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
news@access.fr.vu
------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" <service.informatique@riorges.fr> a écrit dans le message news:
43438f92$0$27413$8fcfb975@news.wanadoo.fr...
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 ?
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" a écrit dans le message news: 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
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
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...
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]
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" a écrit dans le message news: 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
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
news@access.fr.vu
------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" <service.informatique@riorges.fr> a écrit dans le message news:
43439843$0$17222$8fcfb975@news.wanadoo.fr...
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...
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" a écrit dans le message news: 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
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
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 ?
"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]
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" a écrit dans le message news: 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
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
news@access.fr.vu
------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" <service.informatique@riorges.fr> a écrit dans le message news:
43439f05$0$1715$8fcfb975@news.wanadoo.fr...
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 ?
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" a écrit dans le message news: 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
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
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...
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]
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" a écrit dans le message news: 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
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
news@access.fr.vu
------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" <service.informatique@riorges.fr> a écrit dans le message news:
4343a515$0$5380$8fcfb975@news.wanadoo.fr...
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...
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" a écrit dans le message news: 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
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
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...
" 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]
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" a écrit dans le message news: 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
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
news@access.fr.vu
------------------------------------
Site @ccess : http://access.jessy.free.fr/
Pour l'efficacité de tous :
http://users.skynet.be/mpfa/
------------------------------------
"Dan" <service.informatique@riorges.fr> a écrit dans le message news:
4343bd10$0$1738$8fcfb975@news.wanadoo.fr...
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...
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" a écrit dans le message news: 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
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
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...
