JanKusanagi escribió:Puedes no poner la llamada en el href, pero aunque uses el onClick o algo asi, el codigo va a estar ahi, de manera que si estas pasando parametros que no deberian ver... van a seguir pudiendolo ver
RC9 escribió:Encríptalos y en la función los desencriptas pero vamos, el código js también es visible por el cliente.
RC9 escribió:Haz una comprobación antes de insertar para ver si los parámetros son correctos, no se me ocurre otra.
Daicon escribió:RC9 escribió:Haz una comprobación antes de insertar para ver si los parámetros son correctos, no se me ocurre otra.
Los valores no se insertan... los reocojo yo mediante phh, y el usuario no debería de poder modificarlos :-S
$(document).ready(function() {
$('body').on('submit', '.envio-con-ajax', function(event) {
event.preventDefault();
$.post($(this).attr('action'), $(this).serialize())
.done(function(data) {
alert('Éxito!');
})
.fail(function(data) {
alert('Fallo!');
});
return false;
});
});
<form class="envio-con-ajax" action="url-de-destino-al-que-mandar-los-datos-para-su-guardaddo" method="post">
<input type="hidden" name="evento" value="<?php echo $idevento; ?>" />
<button type="submit">Seguir</button>
</form>
Maxtorete escribió:No utilizas ninguna librería JavaScript? Si usas jQuery, por ejemplo, podrías hacer un binding en el evento click de la clase boton_m_seguir, y en el href pones una url alternativa para hacer la misma función en caso de que el usuario no tenga JS o su navegador no soporte los métodos utilizados.
Sobre la visibilidad de los parámetros, si $userm es el usuario actual de la sesión, lo mejor es no pasarlo como parámetro, sino leerlo directamente en la petición en la que vayas a utilizar el dato. En dicha petición, lees el usuario, mira si tiene permiso para realizar la acción, y si es así la ejecutas. Qué más te da que se pueda poner a hacer tonterías? Total, si tiene permiso para hacerlo lo podrá hacer igual desde la interfaz. Si no quieres que haga algo, restríngelo en la aplicación vía permisos.
Eso sí, realizar operaciones a través de una petición GET no es lo más recomendable, ya que get se debería usar sólo para consulta de datos. Así que podrías crear un formulario con un campo hidden idevento y un botón de envío, y hacer un submit vía ajax con el evento click de ese mismo botón. En jQuery (>1.7) sería algo así:
Al final de la etiqueta HEAD:$(document).ready(function() {
$('body').on('submit', '.envio-con-ajax', function(event) {
event.preventDefault();
$.post($(this).attr('action'), $(this).serialize())
.done(function(data) {
alert('Éxito!');
})
.fail(function(data) {
alert('Fallo!');
});
return false;
});
});
En el BODY:<form class="envio-con-ajax" action="url-de-destino-al-que-mandar-los-datos-para-su-guardaddo" method="post">
<input type="hidden" name="evento" value="<?php echo $idevento; ?>" />
<button type="submit">Seguir</button>
</form>
Si el usuario que pasas como parámetro no fuese el mismo, sólo tienes que añadir otro campo hidden con el id, pero ya te digo, si el usuario es el mismo de la sesión, deberías cargar su identificador de la propia sesión para ahorrarte disgustos.
Con todo esto, tu aplicación será algo más segura y en caso de que el usuario no tenga JavaScript o su navegador se haga un lío (hola IE), la aplicación seguirá siendo totalmente funcional.
Daicon escribió:Maxtorete escribió:No utilizas ninguna librería JavaScript? Si usas jQuery, por ejemplo, podrías hacer un binding en el evento click de la clase boton_m_seguir, y en el href pones una url alternativa para hacer la misma función en caso de que el usuario no tenga JS o su navegador no soporte los métodos utilizados.
Sobre la visibilidad de los parámetros, si $userm es el usuario actual de la sesión, lo mejor es no pasarlo como parámetro, sino leerlo directamente en la petición en la que vayas a utilizar el dato. En dicha petición, lees el usuario, mira si tiene permiso para realizar la acción, y si es así la ejecutas. Qué más te da que se pueda poner a hacer tonterías? Total, si tiene permiso para hacerlo lo podrá hacer igual desde la interfaz. Si no quieres que haga algo, restríngelo en la aplicación vía permisos.
Eso sí, realizar operaciones a través de una petición GET no es lo más recomendable, ya que get se debería usar sólo para consulta de datos. Así que podrías crear un formulario con un campo hidden idevento y un botón de envío, y hacer un submit vía ajax con el evento click de ese mismo botón. En jQuery (>1.7) sería algo así:
Al final de la etiqueta HEAD:$(document).ready(function() {
$('body').on('submit', '.envio-con-ajax', function(event) {
event.preventDefault();
$.post($(this).attr('action'), $(this).serialize())
.done(function(data) {
alert('Éxito!');
})
.fail(function(data) {
alert('Fallo!');
});
return false;
});
});
En el BODY:<form class="envio-con-ajax" action="url-de-destino-al-que-mandar-los-datos-para-su-guardaddo" method="post">
<input type="hidden" name="evento" value="<?php echo $idevento; ?>" />
<button type="submit">Seguir</button>
</form>
Si el usuario que pasas como parámetro no fuese el mismo, sólo tienes que añadir otro campo hidden con el id, pero ya te digo, si el usuario es el mismo de la sesión, deberías cargar su identificador de la propia sesión para ahorrarte disgustos.
Con todo esto, tu aplicación será algo más segura y en caso de que el usuario no tenga JavaScript o su navegador se haga un lío (hola IE), la aplicación seguirá siendo totalmente funcional.
Aver, entiendo, lo que dices,, y te explico un poco.
El tema es que utilizo joomla, y hay qu estar con el MVC, y es un poco mas coñazo que eso que me has puesto, y aun estoy aprendiendo.
Tal y como dices, he conseguido obviar el id del usuario.
Pero el problema es el idevento.
Desde el controlador del componente principal, he conseguido acceder al id del usuario actual, asi que ese parámetros desaparece.
El problema es el idevento, que no encuentro forma de conseguirlo sin pasárselo como ahora mismo esta.
En Joomla esta el framework Mootoolos, hay algo similar a lo que me has dicho de Jquery? Podria ser una ayuda.
El problema de que se ponga a tonterar, es que si empiza a poner ids de eventos que no existen, o aleatorias, pues podría empezar a causar problemas (tal vez) en la BD.
Maxtorete escribió:Daicon escribió:Maxtorete escribió:No utilizas ninguna librería JavaScript? Si usas jQuery, por ejemplo, podrías hacer un binding en el evento click de la clase boton_m_seguir, y en el href pones una url alternativa para hacer la misma función en caso de que el usuario no tenga JS o su navegador no soporte los métodos utilizados.
Sobre la visibilidad de los parámetros, si $userm es el usuario actual de la sesión, lo mejor es no pasarlo como parámetro, sino leerlo directamente en la petición en la que vayas a utilizar el dato. En dicha petición, lees el usuario, mira si tiene permiso para realizar la acción, y si es así la ejecutas. Qué más te da que se pueda poner a hacer tonterías? Total, si tiene permiso para hacerlo lo podrá hacer igual desde la interfaz. Si no quieres que haga algo, restríngelo en la aplicación vía permisos.
Eso sí, realizar operaciones a través de una petición GET no es lo más recomendable, ya que get se debería usar sólo para consulta de datos. Así que podrías crear un formulario con un campo hidden idevento y un botón de envío, y hacer un submit vía ajax con el evento click de ese mismo botón. En jQuery (>1.7) sería algo así:
Al final de la etiqueta HEAD:$(document).ready(function() {
$('body').on('submit', '.envio-con-ajax', function(event) {
event.preventDefault();
$.post($(this).attr('action'), $(this).serialize())
.done(function(data) {
alert('Éxito!');
})
.fail(function(data) {
alert('Fallo!');
});
return false;
});
});
En el BODY:<form class="envio-con-ajax" action="url-de-destino-al-que-mandar-los-datos-para-su-guardaddo" method="post">
<input type="hidden" name="evento" value="<?php echo $idevento; ?>" />
<button type="submit">Seguir</button>
</form>
Si el usuario que pasas como parámetro no fuese el mismo, sólo tienes que añadir otro campo hidden con el id, pero ya te digo, si el usuario es el mismo de la sesión, deberías cargar su identificador de la propia sesión para ahorrarte disgustos.
Con todo esto, tu aplicación será algo más segura y en caso de que el usuario no tenga JavaScript o su navegador se haga un lío (hola IE), la aplicación seguirá siendo totalmente funcional.
Aver, entiendo, lo que dices,, y te explico un poco.
El tema es que utilizo joomla, y hay qu estar con el MVC, y es un poco mas coñazo que eso que me has puesto, y aun estoy aprendiendo.
Tal y como dices, he conseguido obviar el id del usuario.
Pero el problema es el idevento.
Desde el controlador del componente principal, he conseguido acceder al id del usuario actual, asi que ese parámetros desaparece.
El problema es el idevento, que no encuentro forma de conseguirlo sin pasárselo como ahora mismo esta.
En Joomla esta el framework Mootoolos, hay algo similar a lo que me has dicho de Jquery? Podria ser una ayuda.
El problema de que se ponga a tonterar, es que si empiza a poner ids de eventos que no existen, o aleatorias, pues podría empezar a causar problemas (tal vez) en la BD.
Pero es que esas posibilidades de tontear debes controlarlas en el controlador: mirar si el id de evento existe, si el usuario tiene permiso para ver/seguir ese evento, si el usuario está siguiendo ya el evento o no, etc. Toda esa capa de negocio la tienes que meter obligatoriamente en el controlador, independientemente de lo oculto que tengas los parámetros, porque sino cualquier aburrido se dedica a hacerle peticiones al servidor y te lo peta en 0,2.
Nunca he trabajado con Mootools, pero no creo que sea muy complicado pasar esa función de jQuery a ese framework, es cuestión de ver la documentación de referencia y cambiar las funciones/parámetros que cambien, pero supongo que la lógica será la misma (interceptar el evento submit para hacerlo vía ajax y según la respuesta del servidor hacer una cosa u otra).
Maxtorete escribió:Pero qué más te da que se ponga a seguir eventos como un loco? Si tiene permisos para hacerlo, pues que lo haga si quiere. La forma correcta de que el usuario no haga esas tonterías es generar un token de seguridad en cada formulario (Drupal y Symfony, por ejemplo, lo hacen, no sé si es el caso de Joomla).
La solución de utilizar la sesión no te la recomiendo en absoluto, al principio puede funcionar y parecer buena idea, pero cuando empiece a fallar y tengas que depurar, te acordarás de esa decisión. Formulario y petición post, no hay más, sin importar la visibilidad de un parámetro. Si lo hacen Facebook, Twitter, Google y compañía, será por algo no?