Estoy reemplazando las cookies con localStorage en los navegadores que pueden admitirlo (cualquiera menos IE). El problema es site.com y www . site.com almacena sus propios objetos localStorage separados. Creo que www se considera un subdominio (una decisión estúpida si me preguntas). Si un usuario estaba originalmente en site.com y decide escribir www . site.com en su próxima visita, todos sus datos personales serán inaccesibles. ¿Cómo hago para que todos mis "subdominios" compartan el mismo localStorage que el dominio principal?

Así es como lo uso en todos los dominios ...

• Utilice un iframe de su dominio principal, por ejemplo, parent.com
• Luego, en cada dominio child.com, simplemente envíe un mensaje posterior a su iframe parent.com
• Todo lo que necesita hacer es configurar un protocolo de cómo interpretar sus mensajes postMessage para hablar con el iframe parent.com.

Espero que ayude :)

Si está utilizando la solución iframe y postMessage solo para este problema en particular, creo que podría ser menos trabajo (tanto en código como en cálculo) simplemente almacenar los datos en una cookie sin subdominio y, si aún no lo está en localStorage on load, cójalo de la cookie .

Pros:

• No necesita la configuración adicional de iframe y postMessage.

Contras:

• Hará que los datos estén disponibles en todos los subdominios (no solo en www), por lo que si no confía en todos los subdominios, es posible que no funcione para usted.
• Enviará los datos al servidor en cada solicitud. No es genial, pero dependiendo de su escenario, tal vez aún menos trabajo que la solución iframe / postMessage.
• Si está haciendo esto, ¿por qué no usar las cookies directamente? Depende de tu contexto.
• Tamaño máximo de cookie de 4K, total en todas las cookies del dominio (gracias a Blake por señalar esto en los comentarios)

Sin embargo, estoy de acuerdo con otros comentaristas, esto parece que debería ser una opción especificable para localStorage, por lo que no se requieren soluciones alternativas.

Sugiero hacer que site.com redireccione a www.site.com tanto por coherencia como para evitar problemas como este.

Además, considere usar una solución de navegador cruzado como PersistJS que puede usar el almacenamiento nativo de cada navegador.

Establecer como cookie en el dominio principal -

document.cookie = "key=value;domain=.mydomain.com"

y luego tomar los datos de cualquier dominio principal o subdominio y configurarlos en el localStorage

Estoy usando xdLocalStorage, esta es una biblioteca js liviana que implementa la interfaz LocalStorage y admite el almacenamiento entre dominios mediante el uso de la comunicación de mensajes de publicación de iframe. (Soporte angularJS)

https://github.com/ofirdagan/cross-domain-local-storage

este tipo de solución causa muchos problemas como este. Por razones de coherencia y SEO, la redirección al dominio principal es la mejor solución.

hazlo redirección a nivel de servidor

Cómo redirigir www a no www con Nginx

https://www.digitalocean.com/community/tutorials/how-to-redirect-www-to-non-www-with-nginx-on-centos-7

o cualquier otro nivel como la ruta 53 si está utilizando

Así es como:

Para compartir entre subdominios de un superdominio determinado (por ejemplo, example.com), existe una técnica que puede utilizar en esa situación. Se puede aplicar a localStorage, IndexedDB, SharedWorker, BroadcastChannel, etc, todos los cuales ofrecen funcionalidad compartida entre las páginas del mismo origen, pero por alguna razón no respetan ninguna modificación a document.domainque ejerzan el superdomain como su origen directamente.

(1) Elija un dominio "principal" para que pertenezcan los datos: es decir, https://example.com o https://www.example.com mantendrán sus datos de almacenamiento local. Digamos que elige https://example.com .

(2) Utilice localStorage normalmente para las páginas de ese dominio elegido.

(3) En todas las páginas https://www.example.com (el otro dominio), use javascript para configurar document.domain = "example.com";. Luego, cree también un oculto <iframe>y navegue a alguna página en el dominio https://example.com elegido ( no importa qué página , siempre que pueda insertar un pequeño fragmento de JavaScript allí. Si ' Al crear el sitio, simplemente cree una página vacía específicamente para este propósito. Si está escribiendo una extensión o un script de usuario al estilo Greasemonkey y, por lo tanto, no tiene ningún control sobre las páginas de example.comservidor, simplemente elija la página más liviana que pueda encontrar e inserte su script en ella. Algún tipo de página "no encontrada" probablemente estaría bien).

(4) La secuencia de comandos en la página de iframe oculta solo necesita (a) configurarse document.domain = "example.com";y (b) notificar a la ventana principal cuando esto esté hecho. Después de eso, la ventana principal puede acceder a la ventana iframe y a todos sus objetos sin restricciones. Entonces, la página de iframe mínima es algo como:

<!doctype html>
<html>
<head>
  <script>
    document.domain = "example.com";
    window.parent.iframeReady();  // function defined & called on parent window
  </script>
</head>
<body></body>
</html>

Si escribir un userscript, puede que no desee añadir funciones accesibles externamente como iframeReady()a su unsafeWindow, por lo que en lugar de una mejor forma de notificar a la ventana principal userscript podría ser el uso de un evento personalizado:

    window.parent.dispatchEvent(new CustomEvent("iframeReady"));

Lo cual detectaría agregando un oyente para el evento personalizado "iframeReady" en la ventana de su página principal.

(NOTA: Debe establecer document.domain = "example.com" incluso si el dominio del iframe ya es example.com : la asignación de un valor a document.domain establece implícitamente el puerto de origen en nulo, y ambos puertos deben coincidir con el iframe y su padre se considera del mismo origen. Consulte la nota aquí: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Changing_origin )

(5) Una vez que el iframe oculto haya informado a su ventana primaria que está listo, la escritura en la ventana padre solo puede usar iframe.contentWindow.localStorage, iframe.contentWindow.indexedDB, iframe.contentWindow.BroadcastChannel, iframe.contentWindow.SharedWorkeren lugar de window.localStorage, window.indexedDB, etc ... y todos estos objetos serán ámbito es el elegido https: // origen de example.com - ¡así tendrán el mismo origen compartido para todas sus páginas!

La parte más incómoda de esta técnica es que debe esperar a que se cargue el iframe antes de continuar. Entonces, no puede simplemente comenzar a usar alegremente localStorage en su controlador DOMContentLoaded, por ejemplo. También es posible que desee agregar algún manejo de errores para detectar si el iframe oculto no se carga correctamente.

Obviamente, también debe asegurarse de que el iframe oculto no se elimine ni se navegue durante la vida útil de su página ... OTOH No sé cuál sería el resultado de eso, pero es muy probable que sucedan cosas malas.

Y una advertencia: la configuración / cambio document.domainse puede bloquear mediante el Feature-Policyencabezado, en cuyo caso esta técnica no se podrá utilizar como se describe.

Sin embargo, hay una generalización significativamente más complicada de esta técnica, que no puede ser bloqueada Feature-Policyy que también permite que dominios completamente no relacionados compartan datos, comunicaciones y trabajadores compartidos (es decir, no solo subdominios de un superdominio común). @Mayank Jain ya lo describió en su respuesta, a saber:

La idea general es que, al igual que antes, cree un iframe oculto para proporcionar el origen correcto para el acceso; pero en lugar de simplemente tomar las propiedades de la ventana del iframe directamente, usa un script dentro del iframe para hacer todo el trabajo, y se comunica entre el iframe y su ventana principal solo usando postMessage()y addEventListener("message",...).

Esto funciona porque postMessage()se puede usar incluso entre ventanas de diferentes orígenes. Pero también es significativamente más complicado porque tienes que pasar todo a través de algún tipo de infraestructura de mensajería que creas entre el iframe y la ventana principal, en lugar de usar las API localStorage, IndexedDB, etc. directamente en el código de tu ventana principal.

Así lo resolví para mi sitio web. Redirigí todas las páginas sin www a www.site.com. De esta manera, siempre ocupará el almacenamiento local de www.site.com

Agregue lo siguiente a su .htacess , (cree uno si ya no lo tiene) en el directorio raíz

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]