Discusión:Intercambio de recursos entre orígenes
 | Este artículo está clasificado como de nivel inicial en la escala de evaluación de contenido de Wikipedia . Es de interés para los siguientes WikiProyectos : | ||||||||||||||||||||
| |||||||||||||||||||||
¿Está realmente obsoleta la recomendación del W3C?
La realidad es que los proveedores de navegadores utilizan la especificación del estándar de búsqueda, no la anticuada especificación W3C. Por lo tanto, no podemos engañar a la gente insinuando que la especificación W3C está actualizada.
Sin embargo, ¿está realmente obsoleta ? La única fuente de la afirmación en la introducción de que la recomendación del W3C está obsoleta es un enlace a las actas de alguna reunión interna del W3C. Eso no demuestra que la hayan desestimado; solo demuestra que algunas personas decidieron hacerlo en una reunión. Al final, puede que haya sucedido o no. Y, de hecho, no sucedió: la resolución en la reunión fue marcar la recomendación como obsoleta oficialmente en el sitio del W3C y agregar una nota a tal efecto en el preámbulo de la especificación. Han pasado años y eso nunca sucedió. Por lo tanto, no podemos afirmar que está obsoleta, al menos no basándonos en esa referencia.
Quizás sea simplemente la inercia burocrática/política del W3C. No lo sé.
Intentaré reformularlo para reflejar la realidad. StormWillLaugh ( discusión ) 13:37 8 dic 2019 (UTC)
Control del lado del servidor vs. Control del lado del navegador
CORS debería ser un control del lado del navegador, pero fue por el camino equivocado, llegó al lado del servidor. Más específicamente, cuando estás en http://www.1st.com/sthFrom1st.html, quieres acceder a http://www.2nd.com/otherthing.html con javascript o un applet de java. Tu navegador no lo permitirá debido a la "política del mismo origen". Ahora, para extender esto, también es una política para el navegador, entonces, ¿por qué entrar al lado del servidor para controlar el servidor? ¿Te volviste loco? CORS es un control del lado del servidor http://www.2nd.com que es diferente de www.1st.com.
La página web sthFrom1st.html debe indicar al navegador web qué sitios pueden considerarse como del mismo origen.
De hecho, creo que esto es fácil de especificar. En el encabezado html, podemos especificar a qué dominios adicionales se les debe permitir el acceso. Los navegadores los leen y, a continuación, el dominio original y los dominios adicionales se consideran todos del mismo origen. Actualmente, es el navegador el que nos bloquea. Estoy en http://1st.com/a.html, luego accedo a http://2nd.com/d.html, con ajax o xmlhttprequest, uso firefox, puedo ver claramente que el servidor remoto devuelve todo y todo está bien. pero el navegador no me permite acceder al contenido. Jackzhp ( discusión ) 23:58, 25 de junio de 2011 (UTC)
- Este no es el lugar adecuado para discutir el futuro de la tecnología de los navegadores. Te sugiero que lleves tu caso de uso y tu propuesta a la lista de correo del Grupo de Trabajo de Aplicaciones Web del W3C , donde se está desarrollando CORS, la especificación de control entre dominios en tu terminología y el tema de esta entrada. Borraré tu sección por el momento, ya que el término "nosotros" (y también cosas futuras) es bastante raro en Wikipedia. — Kennyluck ( discusión ) 22:29 27 jun 2011 (UTC)
- Para mi propia referencia, en el lado del cliente, se debe utilizar la Política de Seguridad de Contenido , mientras que las cuestiones relacionadas con CORS deben estar en el lado del servidor. Y la situación actual se explica en la sección BULLSHIT a continuación. Jackzhp ( discusión ) 07:08, 21 de octubre de 2017 (UTC)
Movimiento solicitado
- La siguiente discusión es una discusión archivada de una mudanza solicitada . No la modifique. Los comentarios posteriores deben realizarse en una nueva sección en la página de discusión. No se deben realizar más modificaciones en esta sección.
El resultado de la solicitud de traslado fue: movido a Intercambio de recursos entre orígenes . Favonian ( discusión ) 22:08 16 feb 2012 (UTC)
Uso compartido de recursos entre orígenes → Uso compartido de recursos entre orígenes – Casos oracionales. http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Article_titles XP1 ( discusión ) 13:27 9 feb 2012 (UTC)
- Soporte . Borrar mayúsculas y minúsculas WP:CAPS . Jenks24 ( discusión ) 05:41 10 feb 2012 (UTC)
- Soporte por usuario:Jenks24 . Me encontré con muchas cosas así cuando ordenaba la categoría:Acrónimos . Callmederek ( discusión ) 22:03 16 feb 2012 (UTC)
- La discusión anterior se conserva como archivo de una solicitud de traslado . No la modifique. Los comentarios posteriores se deben realizar en una nueva sección de esta página de discusión. No se deben realizar más modificaciones en esta sección.
URL en ejemplos
La siguiente URL, utilizada en la sección "ejemplo simple", no sigue las mejores prácticas estándar. Según RFC 2606:
http://www.ejemplo-red-social.com
Debería ser:
http://servicio-de-red-social.ejemplo.com
— Comentario anterior sin firmar añadido por 190.18.14.46 (discusión) 16:08, 1 enero 2013 (UTC)
Referencias huérfanas enIntercambio de recursos entre orígenes
Reviso las páginas que figuran en la Categoría:Páginas con formato de referencia incorrecto para intentar corregir los errores de referencia. Una de las cosas que hago es buscar contenido de referencias huérfanas en artículos con enlaces wiki. He encontrado contenido para algunas de las referencias huérfanas de Cross-origin resource sharing , el problema es que encontré más de una versión. No puedo determinar cuál (si es que hay alguna) es la correcta para este artículo, por lo que solicito a un editor sensible que lo revise y copie el contenido de referencia correcto en este artículo.
Referencia denominada "ars-blink":
- De Opera (navegador web) : "Google sigue su propio camino y bifurca el motor de renderizado WebKit". Ars Technica . Consultado el 4 de abril de 2013 .
- De Blink (motor de diseño) : "Google sigue su propio camino y bifurca el motor de renderizado WebKit". Ars Technica. Abril de 2013. Consultado el 4 de abril de 2013 .
Me disculpo si alguna de las anteriores es idéntica; soy solo un simple programa de computadora, por lo que no puedo determinar si las diferencias menores son significativas o no. AnomieBOT ⚡ 03:51, 30 de agosto de 2015 (UTC)
Mantenimiento y calificación de artículos de JavaScript
Respecto a la edición y mantenimiento de artículos relacionados con JavaScript...
Colaboración...
Si estás interesado en colaborar en artículos sobre JavaScript o te gustaría saber en qué áreas podrías ayudar, visita Wikipedia:WikiProject JavaScript y no dudes en agregar tu nombre a la lista de participantes. Tanto editores como programadores son bienvenidos.
Dónde incluir artículos de JavaScript
Hemos encontrado más de 300 artículos relacionados con JavaScript hasta el momento. Si encuentras otros, agrégalos a la lista.
Scripts de usuario
El WikiProject también se está encargando de la organización de las páginas de soporte de scripts de usuario de la comunidad Wikipedia. Si estás interesado en ayudar a organizar la información sobre los scripts de usuario (o tienes curiosidad por saber qué estamos haciendo), ¡ háznoslo saber !
Si necesitas un script de usuario que aún no existe, o tienes una idea genial para un script de usuario o un gadget, puedes publicarla en Wikipedia:Scripts de usuario/Solicitudes . Y si eres un programador de JavaScript, ese es un gran lugar para encontrar tareas si estás aburrido.
Cómo denunciar artículos de JavaScript que necesitan atención
Si encuentra un artículo de JavaScript que necesita desesperadamente la atención del editor y está más allá de su capacidad para manejarlo, puede agregarlo a nuestra lista de artículos relacionados con JavaScript que necesitan atención .
Clasificación de artículos de JavaScript
En la parte superior de la página de discusión de casi todos los artículos relacionados con JavaScript hay una plantilla de JavaScript de WikiProject donde puedes registrar la clase de calidad y la importancia del artículo. De esta manera, la comunidad podrá seguir el estado de avance y vigilar más de cerca los artículos de mayor prioridad.
Gracias. El Transhumanista 01:07 12 abril 2017 (UTC)
MIERDA
¡Amigo, toda esta estupidez paranoica en materia de seguridad está destruyendo Internet! — Comentario anterior sin firmar añadido por 185.51.75.214 (discusión) 16:43 13 abr 2017 (UTC)
- Puedo ver que estás frustrado como yo lo estaba. Finalmente me di cuenta de que nuestra frustración provenía del hecho de que esas personas inteligentes no estaban dispuestas a aclarar por qué CORS es realmente necesario. Realmente quiero cambiar el primer párrafo del artículo, pero hay muchas personas a las que les gusta eliminar lo que edito, así que lo puse aquí: Jackzhp ( discusión ) 07:06, 21 de octubre de 2017 (UTC)
- CORS es un mecanismo para que un servidor web delegue su comprobación de autorización basada en origen/referencia a los navegadores web. ¿Por qué es necesaria la comprobación de autorización basada en origen/referencia? Dado que un navegador web puede abrir varios sitios web al mismo tiempo, en el caso de un sitio con datos confidenciales, al menos no se debe permitir que otros sitios web accedan a los datos confidenciales a menos que se indique lo contrario, como se hizo con la Política de seguridad de contenido. Para que el servidor web permita que otros sitios específicos accedan a sus recursos, el servidor web debe verificar el origen de la solicitud antes de atenderla. Esta es la comprobación de autorización basada en origen/referencia. Sin embargo, en la actualidad, casi todos los servidores web dan por sentado el supuesto de que otros sitios web no accederán a los datos confidenciales de mi sitio, lo que está garantizado por la antigua política de origen/sitio, no realizan la comprobación de autorización basada en origen en absoluto. Es decir, la comprobación de autorización basada en origen se delega a los navegadores web. Y luego, cuando los datos confidenciales de un sitio web otorgan acceso a algunos sitios específicos, puede lograrlo solo notificando a los navegadores web con CORS. Es decir, delegar aún más la verificación de autorización basada en el origen a los navegadores web. Jackzhp ( discusión ) 07:06 21 oct 2017 (UTC)
¿Qué problemas resuelve CORS?
El artículo sugiere que CORS permite eludir la política de seguridad del mismo origen. Pero esa explicación no tiene sentido. Deshabilitar la política por completo haría lo mismo. Uno esperaría que CORS de alguna manera proporcione una alternativa a la política de seguridad del mismo origen. Pero ¿cómo es segura? ¿Cómo impide CORS a un actor malicioso? — Comentario anterior sin firmar agregado por 76.17.159.243 (discusión) 03:06, 22 de junio de 2023 (UTC)
¿Es correcto "mismo" en "la política del mismo origen con comodines es ..."?
Donde el texto dice:
Una política de comodín del mismo origen es apropiada...
y:
Una política de comodín del mismo origen también se utiliza de forma amplia y apropiada...
¿No es incorrecta la palabra "mismo"? En esos casos se habla de casos en los que el origen no es el mismo que el servidor al que se llama, ¿no?
Dsb765 (discusión) 00:43 30 jun 2020 (UTC)
La primera oración del artículo era confusa y posiblemente engañosa sobre qué son los CORS.
La primera oración del artículo era confusa y posiblemente engañosa sobre qué son los CORS, lo que tiene consecuencias desastrosas para la seguridad web considerando la cantidad de desarrolladores web que no comprenden los conceptos básicos. La nueva es más precisa, exacta e inteligible. Como referencia:
- El antiguo: "CORS es un mecanismo que permite acceder a recursos restringidos de una página web desde otro dominio fuera del dominio desde el que se sirvió el primer recurso.
- El nuevo: “CORS es un mecanismo que permite a una página web acceder a recursos restringidos de un servidor en un dominio diferente del dominio que sirvió la página web”.
