Tampermonkey tiene una advertencia de desaprobación para la declaración @include para mis scripts de usuario:
// @include /https\:\/\/([az\.]*\.)?(((stackexchange|askubuntu|superuser|serverfault|stackoverflow|stackapps)\.com)|(mathoverflow\.net))\/.*/ // @exclude /^https://(chat|api|data)\./ // @exclude https://stackexchange.com/*eslint: userscripts/better-use-match: el uso de @include es potencialmente inseguro y puede quedar obsoleto en Manifest v3 a principios de 2023. Cambie a @match.
La documentación para @match dice:
Más o menos igual a la etiqueta @include. Puede obtener más información aquí . Nota: la
<all_urls>aún no se admite y la parte del esquema también aceptahttp*://.Se permiten varias instancias de etiquetas.
Sin embargo, a pesar de esta documentación poco útil, no son equivalentes en absoluto. Esto no funciona:
// @match /https\:\/\/([az\.]*\.)?(((stackexchange|askubuntu|superuser|serverfault|stackoverflow|stackapps)\.com)|(mathoverflow\.net))\/.*/ ¡El enlace aquí no menciona las expresiones regulares en absoluto! ¿Cómo convierto esta expresión regular para que funcione en @match ?
@match no admite expresiones regulares en absoluto, solo admite globbing. Deberá convertir su expresión regular en varios globos.
La forma en que se procesa @match es que la directiva se divide en tres y las partes se agrupan en varias partes de la URL por separado:
// @match PROTOCOL://HOSTNAME/PATHEsto se hace de manera diferente a include, donde la directiva include se comparó con la URL completa. Consulte: ¿Cuál es la diferencia entre @include y @match en los scripts de usuario?
// @include https://*.example.com/* tenía una vulnerabilidad de seguridad potencial porque un atacante podría crear una URL como https://attacker.example/?.example.com que permitiría que su script de usuario se ejecutara en el dominio del atacante. Dependiendo de lo que haga su script de usuario, podría permitir que el atacante use su script maliciosamente para robar datos de sus usuarios, engañar a sus usuarios o usarlos como parte de un DDOS.
Si sus expresiones regulares eligieran entre varios dominios diferentes, deberá dividir su expresión regular @include en muchas directivas @match con globs. Tenga en cuenta que al hacer coincidir los nombres de host, *.stackoverflow.com también coincide con stackoverflow.com sin subdominios.
// @match https://*.stackexchange.com/* // @match https://*.stackoverflow.com/* // @match https://*.askubuntu.com/* // @match https://*.superuser.com/* // @match https://*.serverfault.com/* // @match https://*.mathoverflow.net/* // @match https://*.stackapps.com/* // @exclude /^https://(chat|api|data)\./ // @exclude https://stackexchange.com/* Debido a que los globs son menos expresivos que las expresiones regulares, algunas directivas @include no podrán expresarse como @match . Si está utilizando una expresión regular para buscar coincidencias con rutas de URL muy específicas en un sitio, es posible que deba mover la lógica para determinar si su secuencia de comandos de usuario debe ejecutarse o no en una ruta particular a las reglas @exclude o a su propia secuencia de comandos.
También hay nuevas restricciones sobre los nombres de host. El comodín debe ir al principio y debe ir seguido de un . . Por lo tanto, no es posible hacer coincidir todos los TLD con example.* , ni tampoco los nombres de dominio parciales como *example.com . Consulte la documentación de Google sobre patrones de coincidencia para obtener detalles completos.
Nota: si anteriormente usaba directivas @exclude , no necesita realizar ningún cambio en ellas. La directiva @exclude no está en desuso. Debido a que excluye dominios, en lugar de @exclude introduzca vulnerabilidades de seguridad.