Apparent problème avec navigateur midori

Bonjour,

c’est assez curieux … je n’arrive pas à me conecter avec mon identifiant/motdepasse sur césium … ça ne génère pas la bonne clé et cela après de nombreuses saisies … avec le navigateur web midori
G.

sur G1 ou sur Gtest …lol !!! t’est sur que t’"est en azerty re lol, et sans rire j’ai eue le souci (pas avec midori , je le connaissais pas celui là …) par rapport à des caractère spéciaux non conforme ou non reconnu , voilou, je sais pas si ça peut te guider mais bon @++ !

merci … je verifie …

sur Ǧ1 … j’ai changé l’encodage des caractères de iso-89 etc… à UTF8 … pareil @++

quand je change l’identité du navigateur ??? enfin bref … rideau “midori” excellent par ailleurs … poids plume.

As tu testé un copier collé depuis un fichier texte ou de préférence keepass, afin de t’assurer de la correspondance des caractères?

… je viens de faire un copier-coller …tjrs le même problème … j’ai des caractères spéciaux et ça ne passe pas …
Ce qui me parait étonnant c’est que le pop-up de césium qui demande le salt et le mdp est le même pourquoi
alors ce comportement ? peut-on mettre un salt avec un caractère d’échappement pour les caractères spéciaux ?

j’ai essayé avec la notation html des caractères spéciaux UTF-8 … ça ne donne rien
je laisse tomber

Tu peux essayer d’ouvrir la console javascript de ton navigateur et regarder ce que renvoient
$("input[name=username]").value; et $("input[name=password] »).value;

Le premier devrait donner ta passphrase, le deuxième ton mdp.

il n’y a apparement pas de console javascript pour le navigateur midori
Enfin ça marche avec chromium,firefox et konqueror … tant pis pour césium sous midori

Personnellement, j’évite les caractères spéciaux dans les données d’authentification.

Pourquoi ?

Ce sont des données qui doivent être portables, et donc fonctionner sur toutes plateformes.

Entre le clavier, l’encodage de l’os, l’encodage de l’interface de l’application cliente, l’encodage supporté par le serveur, et celui supporté par la base de données, je vous laisse deviner le risque potentiel de plantage.

1 Like

For the version currently included in the Ubuntu Repos (0.4.7)

I was unable to find the shortcut to open the Web-Dev tools, but going to the menu (the cog-like button on the right) and click inspect page. Then it will open a window, which is exactly like chrome/chromium’s one (DOH, ITS WEBKIT-BASED!).

Hope this helps someone who is looking on the net for something similar to this.

For the newer version (0.5.7):

Ctrl+Shift+I - Which is the default in chrome(and I think in FF)

NOTE: The versions mentioned above are up to date for the current date.

extrait de

Mais le post est un peu vieux

1 Like

Ce qui est curieux … c’est que le popup d’identification contient une balise input en pure html … peut-être la feuille de style
mais je dis peut-être une bêtise

input ng-if="!showSalt" name=“username” placeholder=“Identifiant secret” ng-model=“formData.username” ng-model-options="{ debounce: 650 }" class=“highlight-light ng-pristine ng-empty ng-invalid ng-invalid-required ng-touched” required="" type=“password”

Je n’ai pas compris ce que tu veux dire ? Oui il s’agit de formulaires avec ces éléments, je ne vois pas ce qui te chagrine à propos ?

Le fait de cliquer sur “inspect page” fait planter midori … oups … sur la debian stretch

1 Like

#LOL :wink:

dommage et désolé ! [troll] peut-être le signe que c’est le moment de choisir un nouveau destrier pour parcourir les plaines des internets ! [/troll]

Merci quand même … j’ai ce qu’il faut chromium, firefox et konqueror où là cela fonctionne correctement

Pour la science ça aurait été pratique de trouver l’origine du plantage. Mais en effet, ça peut venir de l’échappement de caractères spéciaux, d’un bout de javascript qui fonctionnerait mal ou plein de choses !