La gente a menudo piensa que debido a que están usando solicitudes de Ajax, las sessions regulares no funcionan. Ellas hacen. Si tiene un punto final para eliminar algo de la base de datos que está visible en el código fuente, como:

 example.com/user/1/delete

Puede proteger esta solicitud de usuarios no autenticados de la misma manera que lo haría al usar una solicitud HTTP que no sea Ajax en el navegador. Uso de sesiones . Si el usuario tiene los privilegios para eliminar usuarios, esta ruta funcionará; de lo contrario, devolverá un error (o no hará nada).

También puede proteger una API mediante OAuth. Hay un gran documento aquí que explica cómo funciona: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/

La mayoría de las respuestas no son útiles si tiene su aplicación y su API en dominios separados, por ejemplo app.example.com y api.example.com ; en ese caso, las sesiones no funcionarán y tendría que recurrir a OAuth, que es un martillo bastante grande para un problema tan simple.

Esto es lo que haría:

Supongo que tiene usuarios en una base de datos y un identificador único como user_id=12345 . También asumo que tiene sus trabajos en una base de datos y también tienen identificaciones únicas como job_id=6789 .

Primero, en app.example.com , encripta ambas identificaciones con algo rápido y fácil como Blowfish:

 $secret_uid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($user_id)); $secret_jid = mcrypt_encrypt(MCRYPT_BLOWFISH, "your_secret", strval($job_id));

Supongo que su punto final funcionaría algo así:

 api.example.com/jobs/delete/<job_id>/<user_id>

así que ahora desde Ajax llamas a ese punto final, pero en lugar de llamar con ID simples

 api.example.com/jobs/delete/6789/12345

lo llamas con los ID encriptados:

 api.example.com/jobs/delete/6A73D5B557C622B3/57F064C07F83644F

En el lado de la API de su software, descifra los parámetros:

 $jid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_1>); $uid = mcrypt_decrypt(MCRYPT_BLOWFISH, "your_secret", <param_2>);

Ahora puede buscar uid y jid en su base de datos y realizar cualquier tarea que planee realizar. Por supuesto, asegúrese de que un usuario solo pueda eliminar sus propios trabajos.

Admito que esta no es una solución al 100%, pero deja al atacante con muchas conjeturas: tendría que adivinar el id_usuario y un id_trabajo coincidente, el algoritmo de cifrado y su secreto. No protege contra la ejecución de millones de intentos de fuerza bruta para adivinar un par coincidente, pero pone las probabilidades a su favor (y debería tener algún tipo de protección de limitación de cuota de sus puntos finales de todos modos).

¡Buena suerte!

No hay uno. Si le das a alguien algunos datos, entonces pueden procesarlos de la forma que quieran. No puede controlar lo que le sucede después de que abandona su servidor.

Del mismo modo, no puede controlar qué datos envían al punto final.