![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Una pregunta: ¿este comportamiento se presenta con las dos modalidades de marcadores o sólo con la que abre una nueva ventana?
// Saludos |
|
#2
|
||||
|
||||
|
Hola,
Ocurre con ambos Marcadores Román. Ambos funcionan "en local" y no lo hacen "en el Servidor". Y el caso es que son unos puñeteros estos Marcadores... acabo ahora mismo de cambiar "al antiguo sistema", de enviar los datos a la página "marcador.php" y de ahí redireccionar (vía JavaScript) a la página del formulario para añadir enlaces. Me convence la solución, puesto que la redirección no es "pesada" (apenas un par de segundos) y entonces todo va como se espera. Además, no es exactamente el "anterior sistema", porque, no se insertan los enlaces en "marcador.php", sino que esta página, este Script, únicamente está ahí para redireccionar... para que funcione la cosa, vamos. Peeeeeeeeeeero... siempre hay un pero. Resulta que los Marcadores no estaban guardando los acentos, las eñes, en fin, algunos caracteres "especiales" y esta mañana, al tratar de mejorarlos añadiendo la descripción de los enlaces a los Marcadores, aproveché para que cada valor pasado lo hiciera antes por la función "encodeURIComponent" de JavaScript... Estupendo. Ya era posible tener acentos, eñes, signos de interrogación, ¡estupendo! Hasta que me he dado cuenta de que al pasar por "marcador.php" esos datos yo no sé qué pasa pero al cabo llegan como antes, esto es, parece que a "marcador.php" llegan los acentos (por poner un caso), pero, cuando salen de "marcador.php" ya no están ahí... y en su lugar están los caracteres "raros" que aparecen... Total, que menuda leche con los Marcadores estos, los problemas que están dando. ¿Otro? Sea. Ahora puedes seleccionar la descripción del enlace, como sabes, pero, al pasar esta a través de la variable, debe producir algún "cortocircuito", porque Apache se niega a servir la URL correspondiente (nuevo.php), sino que podemos ver el bonito error "303, acceso prohibido a este recurso". Si no seleccionas mucho texto para la descripción, vale, pero, como te pases... pues eso. Así que no veas los problemas que están causando los Marcadores, como digo, y, sin embargo, son muy útiles, es decir, merecería la pena tener algo así en condiciones, porque añadir enlaces "automáticamente" es algo muy útil y práctico. En fin. Ya basta. Que no veas qué pesao soy. ![]() Última edición por dec fecha: 06-09-2006 a las 15:58:24. |
|
#3
|
||||
|
||||
|
Cita:
// Saludos |
|
#4
|
||||
|
||||
|
Hola,
Es posible, pero, ¿entonces porqué aparecemos en una página de error HTTP 303, prohibido el acceso al recurso? ¿No debería partirse "el GET" y llegar incompleto si acaso? Bueno. De todos modos esto no es una pregunta, lo cierto es que tal vez bastaría revisar las URLs que causan problemas (demasiada descripción) y tratar ver qué puede estar pasando para terminar en el error 303 que comento. Prometo hacerlo. ![]() Y, en cuanto al problema por el que inicié este Hilo, casi estoy seguro de que se trata de las Cookies, pero, chico, he probado y reprobado y no doy con la tecla. En fin. Tranquilidad, que Zamora no se ganó en un hora, como suele decirse. ![]() |
|
#5
|
|||
|
|||
|
Hola Dec
Vaya pedazo monólogo. Si te digo la verdad no termino de entender lo que te pasa pero tengo algunas dudas: Cita:
Código:
header('Location: entrar/');
1. La configuración del servidor es diferente en local que en remoto. 2. Se realizan consultas AJAX a la vez que se recarga la página. Es muy posible que estes haciendo alguna operación que al realizarse rapidamente (local) funcione bien, pero que cuando hay un pequeño tiempo de espera falle por algún sitio. Siento no poder ayudarte más, pero como te cuento al principio no termino de entender lo que te pasa. |
|
#6
|
||||
|
||||
|
Hola,
Cita:
El problema que tengo creo haberlo "encerrado" en las Cookies. Es un tema de cómo se guardan las Cookies y cómo se recuperan. Sobre esto estoy muy verde, como puede verse. Empero, por las pruebas que he estado haciendo se trata de eso, de las Cookies, que no se están guardando bien, o como debería hacerse, mejor dicho. Porque "lo que falla" es el método "$usuario->Autentificado()", y este método determina si un usuario está o no autentificado en base a... eso es, en base a ciertas Cookies. Ya nos pegaremos con ello Kayetano. Se ve que cuando se "llega" a la página en cuestión las Cookies no están donde deberían, y por eso el método "Autentificado" devuelve "false", que, por otro lado, no está mal que haga esto, en caso de duda, si es que las hubiera: mejor que este método peque por exceso que por defecto, ¿no? ![]() Bueno. Seguiremos informando, supongo, si es que de una vez me dedico a investigar profunda y todo lo seriamente de que sea capaz este tema. De momento, como he dicho, se ha buscado otra solución que parece servirnos. ¡Gracias de nuevo a todos! ![]() |
|
#7
|
||||
|
||||
|
Hola,
Bueno. Pues no podía dejar de decir en este mismo Hilo que ya, por fin, hemos descubierto qué estaba pasando, porqué estábamos teniendo los problemas mencionados más arriba. Al menos creemos haber dado con el problema, vamos, todo puede ser que en realidad sea otra cosa, pero, nos parece que no, que, por fin, podemos dormir tranquilos. La principal causa de preocupación fue siempre que lo que nos ocupa en Loturak funcionase tal como se esperaba en "local", es decir, mientras, precisamente, nos ocupábamos de probar y comprobar que la aplicación funcionaba bien. Era muy extraño que los problemas se dieran únicamente en el "Servidor", y que tuviéramos que redireccionar con JavaScript ahí, y en local bastase con utilizar PHP, tal como queríamos. Ayer, mientras estábamos añadiendo una nueva característica en Loturak: la vista previa de las páginas enlazadas, nos topamos con un problema exactamente igual que el anterior: la redirección que teníamos que llevar a cabo no funcionaba... en el Servidor, pero, sí en local, es decir, estábamos ante el mismo problema, aunque en otro lugar de la aplicación. Pues bien. Esta vez tratamos de hacer varias cosas... similares a las anteriores, pero, esta vez teníamos también la experiencia a nuestro favor. De hecho, ahora mismo, en Loturak, no se redireccionan páginas con JavaScript, porque, en el ínterin hemos descubierto que "a veces" todo va bien redireccionando con PHP (con la función "Header"), y ese "a veces", por supuesto, era un tanto desconcertante. En esta ocasión, ayer mismo, después de haber intentado algunas cosas y quizá presas del tedio y del cansancio, incluso llegamos a escribir al Administrador del Servidor en donde está alojada Loturak (al señor Emilio, vamos, ni más ni menos) y poco después estábamos arrepintiéndonos, y también contentos, porqué no decirlo, porque habíamos dado con la solución al problema, o, por mejor decir, habíamos dado con el problema mismo, para el que no hay solución, nos parece.¿Cómo? ¿Qué estoy tratando de decir? Pues, efecivamente, que el problema lo tenía yo en mi ordenador: el problema estaba en el uso del "cortafuegos" ("FireWall") de que me valgo: ahí estaba el problema y no en otro sitio, y es que, como hemos dicho más arriba, era algo extraño que funcionase bien en local y no lo hiciera en el Servidor... ¿porqué no iba a hacerlo de la misma manera? ¿Es que el código mutaba en el Servidor y se transformaba en otra cosa? Así es, amigos, resulta que mi "FireWall", por algún motivo (falta de conocimientos, lo que lleva a una falta de optimización, es decir, de configuración, que estos programas necesitan acaso más que otros), digo, que por algún motivo el "FireWall" estaba impidiendo que algunas redirecciones se llevaran a cabo convenientemente: fue quitarle del medio y comprobar como todo bien, esto es, como se esperaba que fuese. La moraleja de todo este rollo, si es que la hay, es que a veces queremos culpar de los problemas a otros, no sistemáticamente, pero, luego de haberles dado vueltas y no haber encontrado la solución: ¿cómo vamos a ser nosotros culpables de nada? Aunque hablar aquí de culpables y culpas tal vez esté absolutamente de más. Sólo quería que supiérais que todo va bien, que los problemas no estaban en el código, ni en PHP, ni en las Cookies, ni en el Servidor, ni en ningún sitio, sino en el cortafuegos de que nos valemos para andar un tantito más seguros por ahí. En este momento Loturak está en el "lugar reservado" para las páginas Web que consideramos seguras, es decir, el cortafuegos se muestra un tanto más benevolente con ella. ![]() ¡Muchas gracias a todos los que intentásteis echar una mano! ![]() Última edición por dec fecha: 15-09-2006 a las 15:18:20. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Funciones/variables Globales | Jad | C++ Builder | 3 | 15-05-2006 19:22:41 |
| Variables Globales | Abel Garcia | Firebird e Interbase | 8 | 26-09-2005 15:20:59 |
| !variables globales en novell | Carlosguiland | SQL | 1 | 10-05-2005 16:32:17 |
| Variables globales en PHP | JulioGO | PHP | 3 | 08-04-2005 14:36:57 |
| Variables Super Globales | JANDREGUE | Varios | 1 | 18-03-2005 18:03:16 |
|