Rôle de l'attribut TARGET

Bonjour,
lorsque que je mets l'attribut TARGET="info" dans différentes balises <A, toutes les pages visées s'ouvrent dans le même onglet.
Mais si je fais la même chose dans une page qui a elle-même été créée par un appel à window.open(...), alors là chaque hyperlien va ouvrir un nouvel onglet, comme si l'attribut TARGET était ignoré.
J'ai ce comportement sur Chrome et sur Firefox.
Ma première question est : quelle en est la raison, s'il y en a une ?
2° y a-t-il un moyen de forcer l'ouverture sur le même onglet ?

pour ouvrir un lien dans l'onglet actuel, il suffit de ne pas mettre d'attribut "target".
regardez la documentation là pour plus d'informations sur les valeurs utilisables :
https://developer.mozilla.org/fr/doc...ement/a#target

Bonjour,
Oui, bien sûr, ça je le sait bien, mais je veux utiliser an autre onglet que celui de la page principale, pour tous les liens qui donne de l'info, sans perdre ma page principale..

Salut
Dans différente j'utilise target="_blank" et je reste bien dans la même session du navigateur, mais cela ouvre un onglet ou la page appelée s'affiche.

Bonjour, et merci.
Quand on utilise _blank, ça ouvre un nouvel onglet à chaque fois. C'est justement ce que je ne veux pas, j'utilise TARGET="info" parce que je veux utiliser toujours le même.
Mon point est que ça marche très bien quand on est dans une page ordinaire, mais si la page a été ouverte par la fonction window.open(), alors TARGET="info" se comporte exactement comme TAGET="_blank". C'est ça le problème.
Je prépare un test pour illustrer le problème en ligne.

Nul ne peut prétendre connaitre toutes les nouveautés.
J'ai donc recherché TARGET="info" avec différents moteurs de recherche, résultat, "info" n'a jamais été trouvé comme valeur de la propriété TARGET.
Je veux bien croire que je n'ai rien compris ...

Citation:

---

Envoyé par ProgElecT

"info" n'a jamais été trouvé comme valeur de la propriété TARGET

---

"info" n'est qu'un nom donné à la fenêtre/onglet/cadre cible. Ca aurait pu être "toto", "barnabe" ou "quesaisjeencore". En dehors des valeurs mots-clés (cf le lien de mathieu plus haut), on peut lui donner n'importe quelle autre valeur :
https://j-willette.developpez.com/tu...ge_2#LII-E-2-b

Bonjour,
J'ai fini par circonscrire et comprendre le problème.

Code:

---

1 2	<A HREF="https://www.google.com" TARGET="info">Google</A><BR> <A HREF="test.htm" TARGET="info">Page locale</A><BR>

---

Voici deux liens, l'un ouvre une page à l'extérieur dans l'onglet "info", l'autre ouvre une page locale sur l'onglet "info".
Pour la page locale, chaque fois qu'on clique sur le lien, la page locale s'ouvre toujours dans le même onglet. c'est le comportement normal.
Par contre, si on clique sur la page externe, ça ouvre un nouvel onglet à chaque fois.

Bon, encore un coup de la police "Cross domain" je suppose, mais là j'aimerais bien comprendre le pourquoi de ce comportement.
Pour protéger qui ? Moi, le serveur externe ? Contre quoi ? Est-ce que le soucis de protection ne commence pas à atteindre le niveau paranoïa ?

J'ai relu la doc sur l'attribut TARGET, on parle d'ouvrir le lien dans un FRAME. Quel FRAME ? Le nouvel onglet n'est pas un FRAME que je sache.
Quand j'ai commencé à travailler en développement WEB, l'attribut TARGET existait déjà en HTML, mais il n'y avait encore aucun IFRAME, ni même de FRAME ou de FRAMESET et encore moins d'onglet. On ouvrait une nouvelle fenêtre, c'est tout.

J'ai essayé d'utiliser la fonction window.open() à la place du lien et de fermer la fenêtre avec la fonction close(). Ça ne marche pas non plus : On ne peut pas fermer une fenêtre créée par javascripte si elle contient une page d'un autre domaine.

Si jamais qqun avait une idée pour contourner cette barrière, je suis preneur.
Merci.

Ouais, je crois plutôt qu'à chaque fois que des sécurités cross-domain ont été nécessaires, tu ne t'es pas demandé pourquoi. Et c'est fort de cette totale absence de connaissance que tu t'interroges, et non pas au nom de la liberté de faire des trucs.

En l'occurrence c'est pourtant super simple.

Un site pirate A annonce qu'il existe une fonctionnalité super pratique sur le site de la banque B mais c'est dommage elle est cachée pour l'instant, pas sûr de pourquoi, sans doute qu'avec cette astuce les clients s'organiseraient mieux et perdraient moins d'argent en frais inutiles. Que ça fasse perdre moins d'argent ce serait pas forcément le cas de tout le monde, par contre c'est un gestionnaire de budget super pratique, et totalement sécurisé puisque faisant partie de la banque.

La méthode est simple : un premier clic ouvre le site de la banque dans un nouvel onglet. C'est important parce qu'il faut une session ouverte sur la banque. Donc bien regarder l'URL au-dessus que c'est bien celui de la banque et tout. Au pire dans cet onglet, ré-ouvrir le site de la banque avec le raccourci du navigateur (mais bon personne ne va le faire.) L'utilisateur y va, en effet, c'est bien le site de sa banque qui connaît les comptes actuels et leurs montants.

Ensuite on accède à la fonctionnalité cachée avec un deuxième clic sur un deuxième lien. Effectivement, l'onglet de la banque change de page, on est sur une nouvelle page de ce site. Là pour accéder à la fonctionnalité, il faut une authentification forte, après il y a des données sensibles à manipuler pour faire son budget. Donc l'utilisateur tape ses identifiants secrets sur cette page.

En réalité cette nouvelle page n'était pas sur le site de la banque, mais sur un autre qui se fait passer pour elle, et qui reprend la même apparence graphique. L'utilisateur qui ne s'en doute pas et est en train d'utiliser le même onglet que celui qui contenait le site de sa banque, lui fait donc toute la confiance qu'il fait à sa banque.

Bon je fais l'exemple de la banque parce que c'est le plus parlant. Mais ça marcherait avec n'importe quel site avec authentification pour lequel il y a un enjeu, et ceux-là ne font pas de vérification supplémentaire avec le mobile. Et puis on peut imaginer récupérer n'importe quel genre d'information, genre la clé d'un portefeuille crypto.

Citation:

---

Si jamais qqun avait une idée pour contourner cette barrière, je suis preneur.

---

- Faire ta propre appli au lieu d'utiliser un navigateur.
- Prendre le code source de Firefox ou de Chromium, en enlever cette sécurité (ou vérifier s'il y a pas une config qui l'enlève,) et utiliser ce navigateur modifié au lieu d'un navigateur normal.
- Si les deux domaines sont partenaires et veulent faire les choses ainsi, voir ce que Content-Security-Policy: frame-ancestors 'self' https://lautre.domaine.com; et un peu de frame minimaliste et de tâtonnement peuvent donner.

Bonjour,
Bon, d'accord, pour mon exemple, il y a effectivement une protection qui se justifie, mais moi mon application est sur localhost, c'est sur mon PC, je suis le seul à l'utiliser, je sais ce que je fais, je ne demande à personne de me protéger, il devrait quand même y avoir des exceptions dans ce cas.

avez vous essayé des extensions comme tampermonkey ? elles permettent de contourner certaines sécurités qui sont bloquées dans les pages chargées de façon classique.
https://addons.mozilla.org/fr/firefo.../tampermonkey/

Bonjour,
Non je n'ai pas essayé, d'une façon générale, je me méfie de ces extensions dont la plupart finissent par ne plus fonctionner après un certain nombre de mises à jour du navigateur hôte.
Je vais peut-être y venir, mais pour l'instant j'explore une autre avenue avec Javascript.
Par ailleurs, je me demande un peut comment on peut se procurer des extensions sur le site de Firefox, qui permettent de contourner des mesures de sécurité implantées par Firefox :whistle: