Reprise du message précédent :
Du coup c'est mieux d'utiliser <b> ou <strong> ? J'hésite
Même chose pour <i> et <em>

J'utilise <i> partout parce-que c'est plus court, et je style au besoin

C'est toujours 2o d'économisés sur la BP

 
Jamais fait de SSII de ma vie, et le turnover et changements de direction tous les 18/24 mois suffisent à ne pas avoir la qualité que je recherche.
 
Sachant qu’une boîte avait la qualité mais pas le marché/revenus, donc c’est difficile de juger la valeur d’une boîte sur la qualité de son code...

justement, la doc dit un peu le contraire
"If there is no semantic purpose to using the <b> element, you should use the CSS"
=> "si <b> n'a pas de but sémantique, alors CSS"

PHILIPPE

VIENS ICI QUE J'TE BUTE

 
 
Je relirai avec le doigt la prochaine fois.

Sans rancune

Salut,
 
J'ai une amie qui s'est fait copier son site.
Site original: https://vie-nomade.com
Copie: http://vie-nomade.info
 
En gros, le site pirate embed le site dans une iframe, via un script "go.php" qui appelle le site original, et lui permet au passage de trafiquer des liens d'affiliation etc. Le fait de passer par ce script permet aussi de se prémunir des headers X-Frame-Option (https://developer.mozilla.org/fr/do [...] me-Options).
 
Du coup comme tout passe par son serveur je ne vois pas d'autre option de que blacklister l'IP du pirate via son .htaccess.
 
Mais bon je suis pas du tout expert en sécurité, donc je sais pas s'il y aurait une solution plus pérenne pour ce protéger contre ce genre de trucs? Genre si le mec change d'IP...

oui tu blackliste l'ip du serveur, mais il te faut des logs je pense pour pouvoir trouver l'adresse ip.
Le mieux c'est de tester le site la nuit et regarder l'ip qui se connecte souvent.

 
Il n'y a pas grand chose à faire.
 
je n'ai pas regardé dans le détail comment procède le site pirate et j'évite de me rendre sur ce genre de site, mais grosso modo, il n'existe aucun moyen technique d'empêcher de reproduire un site, même quand cette reproduction est "automatique".
Les request HTTP(S) sont des requêtes HTTP(S) et point barre. On peut modifier le user agent etc... et donc tu ne peux jamais vraiment savoir si c'est un bot qui fait les requests ou pas. Partant de là, tu peux parfaitement avoir un bot qui parse les pages d'un site, les modifie et reconstitue une copie du site ailleurs. Dans ton cas, si c'est une simple iframe qui contient des pages appelées sur ton site depuis le site pirate, tu pourras le bloquer avec son IP oui...
Si par contre, le site pirate utilise des bots qui font des requests HTTP(S) et qui ensuite reconstituent un site miroir modifié, tu ne pourras pas y faire grand chose.

 
C'est un jeu du chat et de la souris et tu perds toujours à ce jeu. La plupart des pirates utilisent des farms d'ordinateurs avec différentes IPs et/ou change tout le temps d'IPs.
 

Merci pour vos réponses.
 
Oui ça a l'air d'un simple script
 

 
Après je sais pas ce qu'il y a derrière son script, si il fait ça à la volée ou s'il stocke la page modifiée chez lui... J'imagine que c'est la première option car la plus simple, mais sans certitude.
 
J'ai fait un whois, le site est enregistré depuis Panama, comme c'est étrange

Tente une plainte auprès de l’hébergeur du site pirate.

Ouais c'est ce qu'elle a fait, et je lui ai conseillé aussi auprès du registrar qui fournit le nom de domaine
 

Il y a une manière bâtarde en plus, ajouter un script dans les fichiers scripts du site, si le site est dans une iframe, le site affiche une popup avec en gros le lien original du site en indiquant bien que le site sur lequel la personne se trouve n'est pas le bon site.
Le lien devra être avec un target="_parent".

A tester

Ca sera déjà ça de pris, après le pirate pourra toujours effacer ce bout de code mais ça le fera un peu chier dans un premier temps tout en alertant les utilisateurs

J'aime.

Tu peux faire directement une redirection en JS si le hostname n'est pas légitime (et logguer le nom qui n'est pas légitime pour en trouver éventuellement d'autres).

nop l'iframe est sandboxée là

nope ta redirection en JS ne pourra peut-être pas se faire car si mes souvenir sont bon, la sécurité des browsers de nos jours empêche une fenêtre appelée dans une iframe de faire une redirection de son parent

Elle peut essayer de peter les liens réécrit : https://developer.mozilla.org/fr/do [...] ement/base
<base target="_top" href="urldebase"/>
Si le script php ne le filtre pas, ça va etre fun

Comme c'est fait ce site : https://www.nationalgeographic.com/ [...] -of-moons/

C'est que du paralax ?

Surtout la navigation entre les différentes lunes quand on scroll, c'est vraiment impressionnant.

 
Ce qui est surtout très impressionnant c'est le lag hallucinant si je ne passe pas Chrome en mode "nvidia".

J'ai pas de soucis sous Chrome avec un MBP 2017.

dite les eleets, en react je suis obligé d'intercepter le onChange des <input> natifs?
https://reactjs.org/docs/forms.html [...] components
 
Je suis en train de faire un window.prompt() dans la page, et le nombre de lignes de code est complètement hors de proportions.

Oui, comme le flux est unidirectionnel faut explicitement refléter les entrées utilisateur dans ton store pour pouvoir les injecter dans ton vdom.  
 
Les formulaires c’est clairement le truc le plus frustrant des vdom unidirectionnels si tu utilises pas des helpers / composants dédiés, d’autant plus parce qu’il y a plein de comportements natifs que tu perds plus ou moins.

J'utilise ce pattern en général

class NameForm extends React.Component {
  
  state = {
     firstInput: 'totot'
  }
  handleChange = e => { // auto bind to this, pas besoin de le faire dans le constructeur
    this.setState({[e.target.name]: e.target.value});
  }
 
  handleSubmit = e =>{
   // j'ai tout mon form dans le state
   e.preventDefault();
  }
 
  render() {
    return (
      <form onSubmit={this.handleSubmit}>
        <label>
          Name:
          <input type="text" name="firstInput" value={this.state.firstInput} onChange={this.handleChange} />
        </label>
        <input type="submit" value="Submit" />
      </form>
    );
  }
}

merci.

Et tu veux ptet plutôt tracker l'event "input" que "change" sur tes <input> : https://developer.mozilla.org/en-US [...] nput_event

tu peux me faire un slide deck sur le débat input vs change stp ? oublie pas le planning, le budget et les ressources, merci.

Iirc le onchange de react c’est le oninput des navigateurs.

https://github.com/facebook/react/issues/3964

 
T'as trouvé les infos tout seul
 

 
Visiblement oui (je fais pas de React )
Et visiblement, vu les commentaires, c'était pas forcément un bon choix

dites, this.setState() ça va déclencher le onChange() de moi-même pour prévenir ceux qui m'observent?

Non. Ça va mettre à jour le state et triggerer un rerender.

merde, je dois déclencher moi-même du coup?

Genre si ton parent te passe un callback en prop? Oui.