#8730 Tampoco es plan de entrar en detalle, pero te voy contestando alguna que otra cosa 
El token con js no sirve de nada, porque hay que hacer un script que sea potencialmente peligroso, bloqueos de carga cuando no toca y sinceramente no no.
Es tan facil como poner un JS con una llamada ajax al servidor que valide al usuario y desde el servidor gestionas el token, los bloqueos y todo, no hay nada potencialmente peligroso ni ningún problema. Lo de los bloqueos innecesarios, pues hombre, ahí tu pones los límites, pero es cuestion de darle una vuelta y analizar las peticiones para hacerlo sin problema.
Que las imagenes se carguen via script es el lazy loading, pero otra vez, no sirve de mucho, porque el bot no esta cargando la pagina con un navegador.
Esto no te lo he puesto para ahorrarte recursos es en tu servidor, si no para que la información en otros sitios esté peor o que automáticamente el usuario que entre vea cosas que no tienen nada que ver
El link canonico, es algo que ya se ocupan de cambiarlo no te preocupes xD.
Si no tienen link canónico, eso que ganas, si tienen link canónico, al poner más de 1 en la página, google ignora todos los que haya (y si despues llega a tu página y lo tienes todo correcto, eso que te ahorras )
Tal como parecen funcionar es haciendo una llamada curl y onteniendo todo el contenido de la web en texto
He montado bots y scrapeadores y por eso te recomiendo todo lo anterior, más que nada pq tu problema es de contenido y se suele copiar/pegar el HTML íntegro que se encuentra en la web que analizas.
Al final las imagenes o el link canonico en estos ataques es lo de menos, van a por el contenido, los textos, uno de los elementos que si esta bien cuidado el
SEO es donde mas ranking organico sacas.
Como he dicho anteriormente, tampoco es plan de entrar en mucho detalle, pero conforme publiques una noticias, puedes notificarselo a google ( para que detecte el contenido antes que nadie y que vea que tu eres el autor, puedes usar microdatos para que si copian/pegan HTML, en todo momento se indique que todo es tuyo ( http://schema.org/Article )... hay muchas formas para ir solucionando las cosas.
Está claro que si la persona detrás tiene mucho interés, irá adaptandose tambien a todo lo que hagas, pero eso también te ayuda a mejorar
#8728 Tampoco es como para ponerlo en un nuevo hilo, además, ahora que llevo medio café, se me ocurre que se puede ser más malvado 
Por ejemplo, si copian íntegramente tu código, puedes colar un javascript que haga en la web replicante lo que quieras, desde mostrar popups, redirigir a tu sitio, redirigir al usuario a sitios de spyware... ( para q google lo detecte y bloqué el sitio por amenazas... ), meter algun link de afiliados, para que si alguien ve alguno de esos blogs y luego compra en amazon te de dinero... xD
Todo depende de como te copien el contenido y como lo repliquen, con un pequeño análisis inicial, es cuestion de darle unas vueltas
#8731MisKo:Es tan facil como poner un JS con una llamada ajax al servidor
Mira prueba a hacer eso y luego abres la terminal y haces curl tu-url.foo. Claro que es potencialmente peligroso, que haces con gente que no utiliza js? Que pasa si la conexion es 3G y la request cuesta hacerse 12 - 15 segundos. La idea no es mala, pero no es la mas apropiada para hacer frente a un scrap bot.
#8731MisKo:Esto no te lo he puesto para ahorrarte recursos es en tu servidor, si no para que la información en otros sitios esté peor o que automáticamente el usuario que entre vea cosas que no tienen nada que ver
La que propones es quitar los links de las imagenes y cargarlas dinamicamente con js? Y si una imagen falla? Y si uno de los editores tiene que cambiar la imagen?
#8731MisKo:He montado bots y scrapeadores
Yo tambien, y te aseguro que nada que puedas hacer en JS puede parar mis bots XD
#8731MisKo:pero conforme publiques una noticias, puedes notificarselo a google
Pero es que no hablamos solo de noticias, hablamos de paginas de noticias, comerciales, etc.
El problema es que los bots que nos atacan no hacian scrapping para pillar alguna parte de contenido, hacian una request para pillar todo el HTML/JS de la pagina, seguian los links y repetian sin unas un navegador, con lo que la forma de pararlos no esta en el front, estaba en el back.
Edit ->
#8731MisKo:Por ejemplo, si copian íntegramente tu código, puedes colar un javascript que haga en la web replicante lo que quieras, desde mostrar popups, redirigir a tu sitio, redirigir al usuario a sitios de spyware... ( para q google lo detecte y bloqué el sitio por amenazas... ), meter algun link de afiliados, para que si alguien ve alguno de esos blogs y luego compra en amazon te de dinero... xD
Esto lo metimos y lo tuvimos que quitar por razones que no puedo comentar, pero no fue muy buena idea.
Tampoco voy a seguir porque si no, si que podría dar para hilo nuevo xD, pero de verdad una peticion por JS y ajax, donde no envias absolutamente ningún dato, te puede tardar de 12 a 15 segs? Acabo de hacer una petición con GPRS ( muy inferior al 3G que comentas ), donde además he enviado email y passw y ha tardado 1.74 segundos ( y eso que envio y recibo datos, mínimos, pero lo hago )
Gente que no utiliza JS? en 2010 era un 2% en USA, con el paso a moviles y tablets, ese % habrá bajado sin problemas y además, seguro que el 90% de las webs no le funcionan actualmente si no tienen JS Habilitado (por cierto, en Europa, si sumamos IE8 e IE9, tambien se van al 1%, y dudo que les des tambien soporte, que oye, tambien te pueden obligar xD, pero no es lo normal )
La que propones es quitar los links de las imagenes y cargarlas dinamicamente con js? Y si una imagen falla? Y si uno de los editores tiene que cambiar la imagen?
Supongo que no me he terminado de explicar bien, pero hablo de la carga en el front, esto no está reñido con como gestionen los usuarios los contenidos en el administrador.
Yo tambien, y te aseguro que nada que puedas hacer en JS puede parar mis bots XD
Nadie ha dicho que se paren solo con JS, como bien te he dicho anteriormente, te encargas de cosas del front y gestionas bloqueos y demás en el back.
#8736 Si el problema es que todas las soluciones o impedimentos que propones son en el cliente y dependen de javascript y los bots/scrappers que te quieren robar el contenido no usan un navegador, no abren la pagina, miran el codigo y la copian, tiran una request y guardan la respuesta.
He visto bots, que tiran la request con regexp incluso.
Todas las medidas que comentas son muy validas, si te enfrentas a un bot que usa un navegador o son script kiddos que hacen sus bots en js xD
#8737 Sigo sin explicarme, te pongo un código que he hecho deprisa y corriendo a ver si más o menos entiendes el concepto.
Todas las medidas que comentas son muy validas, si te enfrentas a un bot que usa un navegador o son script kiddos que hacen sus bots en js xD
Justo al reves, si el bot compilara JS, esta solucion no valdria
#8738 Esa solucion es peligrosa porque puedes acabar bloqueando, como he dicho, a usuarios que no son bots.
muchos frameworks de js pero luego fallais en lo imporante xD
https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf
pag 49
#8744 Eso ya sería otro tema, pero vamos, que la unica forma de evitar que alguien se logue en tu web si le han robado el usuario y la clave es via validación en 2 pasos ( ya sea via auth code por app, comprobar que la IP no es la misma que la última que ha usado y enviar alguna verificación que tenga que validar el usuario, cosas así )
Vamos, si yo ahora mismo encontrara tus datos por internet, con poner el user y pw en mediavida entraría en tu cuenta sin problemas..
#8745 Google es un bot más y no te conviene quitarle el acceso porque el no pueda completar el captcha, ya que toda la problematica es para q no te roben los contenidos que quieras que vea google...
tmb existen los CAPTCHA Bypass... sabeis que hay una botnet que te secuestra el windows si no resuelves captcha de vez en cuando? xD
#8748 El tema de los captcha es un mundo aparte, además que está tirado de precio para software que lo utilice y es todo automatizado. Te ponen a personas 'reales' detrás resolviendolos, que vaya trabajo de chinos, estar todo el dia resolviendo captchas...
Menos mal que Beavis puso los marcadores para los mensajes interesantes, si no, otro tema bueno fagocitado por este hilo.
bueno, la soluciona buena es meter un waf... o programar tu algun tipo monitorizacion que detecte los bots y los bloquee en consecuencia xD
#8753 Pero eso lo puedes ocultar... y los auto-bots que crawlean la web no lo pueden detectar. La comprobación de google-bot la haces server side (bajo PHP/SP, por ejemplo) y si la pasas le vomitas el JS en crudo. Si no la pasas le saltas un captcha. Además en ese PHP/ASP puedes meter la IP de tu cliente habitual y así evitarle la validación del cpatcha.
Todo eso un bot no lo verá ni en pintura.
https://support.google.com/webmasters/answer/80553
https://support.google.com/webmasters/answer/1061943
PD: La ocmprobación se hace por reverse DNS, no por user-agent. A no ser que el bot sepa que dejas pasar a google y te meta un spoof de IP... no podrá dumpear tu código
#8755 Lo primero que se hace al scrapear un sitio es ocultar el scrape, y para eso tiras de los user agents conocidos, ya sea poniendo el de google, el de msn, etc...
Lo del reverse dns, por un lado estaría bien, pero para una web que recibe multitud de visitas desconozco hasta que punto sobrecargaría el servidor y si sería viable.
Y lo del captcha, estamos hablando de webs públicas ( imaginate un blog random ), si tu vas a entrar a un blog y para leer lo que sea tienes q meter un captcha, o lo haces porque ya lo conoces de antes y te interesa, o te vas directamente a otra página y listo.
Si fuera algo que es solo para un cliente habitual, no pondría ni el captcha, simplemente bloqueo por IP o user/login
#8756 Entonces tu solución es dejar de utilizar MIERDAS que se ejecutan client-side (como JS) y pasar a lenguajes profesionales server-side como PHP/ASP.
Una solicitud de reverse DNS tiene practicamente coste 0 de CPU
#8758 Para empezar, me hablas con respeto, que no te he faltado y no soy ni tu amigo ni tu colega y, para continuar, si leyeras un mínimo o tuvieras más comprensión lectora, verías que lo que le he dicho no está centrado en JS.
No voy a seguir discutiendo contigo.
#8759 Si quieres evitar que tu código termine a manos del cliente (un bot por ejemplo), deja de usar lenguajes que se ejecutan/interpretan en la zona del cliente (client-side), ya que siempre serán víctima de ser dumpeados por cualquier bot. Tu alternativa es programar el mismo proyecto en un lenguaje compilado (no interpretado) o en su defecto un lenguaje interpretado en la zona del servidor (server-side). Por otra parte hacer una consulta de DNS inverso tiene un coste de CPU prácticamente nulo.
Mejor?
