He creado un objeto auxiliar para almacenar JSON en el hash URL. Ver proyecto here on GitHub:JSON en URL Hash - ¿Una mala o buena idea?
Esto es útil para la persistencia de configuraciones de página sin una cookie. Funciona bastante bien y me gusta.
¿Cuáles son las ideas a favor y en contra de este enfoque? He leído que la seguridad podría ser. ¿Es realmente cuando está usando json2.js o el objeto JSON nativo en los navegadores más nuevos?
Usted debe conscientes de que hay un límite a la longitud de la URL y se cambió entre diferentes navegadores: http://www.boutell.com/newfaq/misc/urllength.html
No veo esto como un problema, no más que otros esquemas. Gracias por compartir sin embargo. –
rison parece una forma más compacta y eficiente. Sobre todo porque muchos caracteres utilizados en JSON no son seguros para URI.
Además, rara vez es conveniente incluir información confidencial (es decir, la mayor parte) en cualquier cosa que vaya y vuelva entre el servidor y el cliente. Es por eso que la mayoría de los esquemas de "sesión" almacenan solo una ID de sesión en una cookie y no toda la información. En ese caso, agregar el ID a la URL no es más difícil que usar la cookie. De hecho, esa era la forma predeterminada de hacer sesiones en PHP en los viejos tiempos cuando las cookies eran una característica avanzada de algunos navegadores.
Bastante bien - eso es nuevo para mí y me gusta. Para solucionar los problemas con los caracteres seguros de URI, elimino las comillas dobles por completo (otros caracteres como {}, [] y: son seguros para URI, creo). Lamentablemente, la eliminación de las comillas dobles limita el tipo de cadena que puede incrustar ... –
+1 para rison, aunque los problemas con espacios y comillas complican las conversiones. – Christophe
Solo pude encontrar rison aquí https://github.com/Nanonid/rison –
¿En qué parte de la url lo está almacenando? ¿El #fragment o el ?query?
Si se trata de la consulta ... No.
Como aquellos:
En el hash '# fragment'. –
Si el estado se va a gestionar desde un solo navegador, y no se comparte con otros usuarios o navegadores, se mantiene el estado de almacenamiento local puede ser una mejor apuesta. Un marco como amplify.store compatible con la mayoría de navegadores que encontrará (IE 5+, Firefox 2+, Safari 4, Chrome, Opera 10.5 +, 2 + iPhone, Android 2 +): http://amplifyjs.com/api/store/
Es es mucho más fácil de usar que una cookie, mucho más poderosa y no tiene las posibles preocupaciones que menciona @Javier.
Si necesita que el estado se administre en todos los navegadores (y/o usuarios), la url es su mejor opción, y en ese caso yo también miraría a rison.
¿Está poniendo JSON en la URL realmente tan diferente al uso de los parámetros estándar de cadena de consulta? – nnnnnn
Me gusta JSON - debe ser más fácil de leer que una cadena de consulta :) –
Tenga en cuenta que Martin está preguntando sobre el fragmento/hash Url - la parte después del '#'. –