bonjour,

Confronté à des dysfonctionnements de certaines extensions dans la version 55, et anticipant les problèmes à venir avec les prochaines versions, j'ai installé dans MyApps une version 54 de Firefox (et gardé la version courante dans Apps).

ce qui n'est pas sans causer quelques soucis si l'on passe de l'une à l'autre:
- authentification nécessaire dans Keefox (je ne vois pas trop comment y échapper)
- impossibilité de consulter une page depuis un lien dans Thunderbird selon le paramétrage courant dans KFA pour http(s)

je m'explique plus en détail pour ceux qui pourraient être confrontés à la même situation :

dans KFA, on retrouve donc les deux instances de Firefox qui ont chacune une association pour ouvrir un lien http (j'ai renommé une action en 54 pour une meilleure visibilité); aucune n'est marquée comme par défaut.

dans le registre, lorsque l'on a activé les associations des applications portables, on retrouve les deux actions sous HKCR\http\shell :
- une sous open, qui sera utilisée par défaut (ici c'est la 54)
- l'autre sous open_liberkey (la 55)


si l'on lance la version 54 de Firefox, et que l'on demande ensuite à ouvrir un lien http depuis Thunderbird, cela fonctionne car le navigateur par défaut pour http est cette version 54.

si l'on lance par contre la version 55, et que l'on tente la même chose sur Thunderbird, on obtient un message d'erreur pour conflit de version car le navigateur par défaut pour http est la version 54 qui ne peut être lancé en même temps que le firefox actif qui est en 55.


il faut donc aller sous KFA et marquer la version 55 comme "par défaut"

ce qui aura pour conséquence d'inverser l'ordre des actions dans le registre. On trouve alors
- une action open, qui sera utilisée par défaut (la 55 cette fois)
- l'autre sous open_liberkey_54 (appelée ici autrement parce que je l'ai renommée dans KFA)


pour résumer, il faut maintenir la cohérence entre le navigateur défini par défaut pour ouvrir un lien http, et celui utilisé. C'est possible avec KFA en spécifiant à chaque fois que l'on ouvre une des deux instances de Firefox qu'elle est la version à définir par défaut dans le registre.

bon, c'est possible mais un peu fastidieux ;

j'ai donc imaginé de pouvoir automatiser cela, avec deux idées en tête:
1- la première étant de confier à KFA le soin de le faire, en lui spécifiant par ligne de commande un fichier xml de même structure que KeyFileAssoc.xml mais ne contenant que les nœuds config et filetype concernés (ici http et par extension https, html, htm, url) qui spécifierait la version par défaut du navigateur, lui se chargeant de répercuter cela dans le registre.
2- la seconde, d'élaborer un script qui vérifie si la cohérence est établie, et dans le cas contraire, modifie la base de registre pour la rétablir.

la première me semblait plus élégante, mais il faut pour cela que KFA soit multi-instances, qu'il sache exploiter un autre fichier xml que KeyFileAssoc.xml, et que le lancement de cette instance en ligne de commande ne perturbe pas l'activité de l'instance principale de KFA qui gère l'ensemble des associations.

cela ne me semblait pas gagné d'avance , donc avant de vous solliciter j'ai creusé la seconde solution.

j'ai donc écrit un fichier batch (j'ai bataillé ferme car je ne parle pas couramment le batch loin s'en faut ) qui fait ce que j'ai décrit en point 2 avant de lancer FirefoxLKL.exe.

les premiers tests (sur une clé bidon http2) ont fini par fonctionner comme attendu mais cela s'est gâté avec la vraie clé http (j'en vois déjà qui se marrent ).

- cela fonctionne si les associations ne sont pas activées
- mais plus si elles le sont

apparemment, KFA garde jalousement les clés dont il a la charge et restaure immédiatement toute clé modifiée ; enfin c'est ce que j'ai cru comprendre car la commande reg add /f pour forcer la prise en compte du navigateur par défaut réussit mais si je réinterroge immédiatement après la base de registre, c'est la valeur mentionnée dans KFA qui est renvoyée. J'avais pensé à un verrouillage de la clé, mais j'aurais dans ce cas dû échouer dans la commande reg add /f.

ce n'est que lorsque je désactive les associations dans KFA que la valeur que j'avais essayé de forcer est prise en compte. Or, je souhaite conserver actives les associations pour pouvoir utiliser d'autres programmes de la LiberKey.

donc, mon idée 2 tombe à l'eau ; il me reste la solution manuelle ou avec de la chance la solution 1 ?

- KFA est il multi-instances ?
- est-il pilotable en ligne de commande ?
- sait-il tirer parti d'un fichier xml spécifique qu'on lui soumetttrait ?
- et si oui l'instance principale ne risque t'elle pas là encore d'empêcher la modification du registre ?

questions annexes pour satisfaire ma curiosité (si ce n'est pas top secret ) :
- quel est le secret de KFA pour modifier la base de registre sans nécessiter d'élévation de privilège? dans le script, j'y suis tenu ; j'ai cherché sur le net, apparemment c'est impossible en powershell, possible en vbs mais en donnant le mot de passe en clair : pas terrible pour la sécurité...

- où sont stockées les clés que KFA écrase lorsque l'on associe les applications portables, et qu'il restaure lorsque l'on restaure les associations originelles ? par exemple, Internet Explorer est mentionné comme navigateur par défaut avant activation des associations, écrasé par Firefox pendant, et retrouvé après désactivation des associations.

- j'ai joué au petit curieux en ajoutant un paramètre FileToLog dans la config de au fichier de KeyFileAssoc.xml mais le log n'est pas très bavard (en tout cas par défaut) sur son action sur la base de registre : y a t il un mode verbose?

enfin, qu'utilisez vous pour vos scripts ? batch, vbs, js, powershell ? je suis parti en batch car j'avais quelques souvenirs (très brumeux) et n'ai jamais pratiqué les autres mais c'est franchement pénible pour un non intié : syntaxe ultra rigide et rapidement illisible, nombreux pièges, effets de bord vicelards, débugging préhistorique ....

merci d'avoir lu jusque là...

eseb

puis-je espérer une réponse, même succincte ?

eseborange a écrit:puis-je espérer une réponse, même succincte ?

Désolé.. Il m'arrive régulièrement de louper des messages quand le temps me permet de faire un tour sur le forum.
KFA n'a pas besoin d'élévation de privilèges car il ne touche pas aux clés le nécessitant.
Il n'est pas pilotable par batch, ni multi-instance, ni ne permet l'inclusion d'un fichier XML annexe.
Il sauvegarde les informations permettant la restauration des associations originales dans HKEY_CURRENT_USER\Software\Classes\LiberKeyBackup (ce n'est pas un secret d'Etat )
Ce qui te donne l'impression qu'il empêche la modification des clés qu'il gère est probablement dû au fonctionnement de la base de regsitre elle-même.
En effet, les informations concernant les associations de fichiers sont fusionnées depuis plusieurs emplacements réels. Certains ne sont même pas documentés (ou alors j'ai pas trouvé la doc).
De mémoire, KFA ne fait des modifications QUE dans HKEY_CURRENT_USER\Software\Classes. Elles apparaissent fusionnées avec d'autres dans HKEY_LOCAL_MACHINE, mais en réalité elle n'ont pas été modifiée directement à cet endroit.
Les modifs ne sont pas faites par script mais directement depuis l'exécutable KeyFileAssoc.exe et, de mémoire toujours, je ne crois pas qu'on puisse lui demander d'être plus verbeux dans les logs.
Il est certain qu'il faudrait le faire évoluer encore pour palier à certains problèmes qui apparaissent dans les versions les plus récentes de Windows. Malheureusement, Microsoft procède à des changements dans le fonctionnement des associations à chaque version de Windows (ce n'est pas une exagération). Et dans les dernièrs versions il est devenu impossible de se contenter des clés accessibles sans élévation pour gérer correctement tous les cas de figure.
De plus, il n'est plus du tout évident qu'il soit possible, même en élevant les privilèges, de gérer correctement et dans les règles de l'art ces fichues associations. Pour le faire correctement il faut utiliser des APIs spécifiques qui sont apparues peu à peu et qui elles aussi sont modifiées à chaque nouvelle version de Windows.
Au final, on se retrouve avec une usine à gaz et il est vraiment extrêmement compliqué de faire du code qui fonctionne sans élévation et qui soit utilisable dans toutes les versions de Windows.
Je crois que, même si ce n'est pas rare chez MS, la gestion des associations de fichiers est dans le top 10 des trucs les plus foireux de Windows.
Je comprends tout à fait que tu te sois tiré les cheveux en te lançant là dedans.. J'y ai passé quelques nuits blanches dont une bonne partie à chercher des solutions que je n'ai jamais trouvées.