JAMAS ENTENDI ESOS GRAFICOS :V pero entiendo que quieres crear un login con autenticacion la base de datos sql? crea una api con php y la consumes(yo mori en este intento :V) si usas mongodb express nodejs. creo q seria mas facil en

Hola Julio. Normalmente los datos subidos por el usuario se graban en una carpeta creada específicamente para ese usuario y podrían nombrarse con el ID del Usuario (lo cual no es una buena práctica) o con algún UUID o código generado aleatoriamente. La lógica del acceso, en efecto se controla desde la aplicación web, puesto que es un intermediario entre los datos guardados en el servidor y la petición del usuario. Sin importar el lenguaje en el que construyas tu API y/o servidor tendrías que validar:

1. Si los datos de acceso son correctos, guardar la sesión.
2. Verificar el tipo de plan que tiene contratado el usuario y guardarlo en la sesión (o cargarlo a la sesión).
3. La API debe retornar la URL a ese archivo solicitado, en algunas ocasiones puede ser una URL temporal basada en la sesión del usuario. Esto depende de la forma en que lo programes. En este punto es donde se valida no solo si el usuario está logueado, sino también si su plan permite acceso a ese recurso.
4. Si se cierra la sesión, destruir los datos guardados en la sesión.

Esto es algo complejo, piensa en el punto 3. Si el usuario conoce la URL exacta de algún recurso: ¿Podrá el usuario accesar pegando la URL en el navegador sin iniciar sesión? Por ello es que tu servidor debe controlar todas las peticiones.

Un buen ejemplo es EDteam. Si compras un curso puedes tener acceso a ese curso, aunque no tengas el plan premium. Si tienes plan premium puedes tener acceso a todo. Si conoces la URL exacta, puedes ponerla en el navegador, pero el servidor detendrá te negará el acceso porque o no estás logueado o no tienes comprado ese curso o no tienes premium.

En Django por ejemplo existe el Decorador @login_required que justamente solo te permite acceder a una URL si están logueado. Pero esto mismo se puede programar con un conjunto de instrucciones del tipo:

if request.user is None:
   return redirect("/bloqueado")   

If request.user.plan == 1:
   return redirect("/bloqueado")   

O algo así, recuerda que este es solo un ejemplo muy limitado de lo que implica la lógica de control de acceso.

Muchas gracias compañeros por su respuesta, la verdad es que me han ayudado mucho con sus comentarios.

La aplicación estaría construida con Node, Express, Ajax, Websocket y Postgresql.

Ruperto C. Gracias por nombrar la carpeta que se crea específicamente para el usuario, el tío Alexis en un curso nos decía que en la base de datos solo se tendrían que guardar los datos, no imágenes, archivos, pdf, etc... creo que a eso te refieres que sería una mala práctica guardarla en el mismo servidor.

La verdad, es que no sabía que se generaba esa carpeta directamente relacionada con el usuario,(no se prácticamente nada de base de datos) pero me has resuelto totalmente la duda, ya que esa carpeta la guardaré en otro servidor específicamente para guardar ese tipo de datos.

Nuevamente muchas gracias por sus respuestas.

JAMAS ENTENDI ESOS GRAFICOS :V pero entiendo que quieres crear un login con autenticacion la base de datos sql? crea una api con php y la consumes(yo mori en este intento :V) si usas mongodb express nodejs. creo q seria mas facil en

Hola Julio. Normalmente los datos subidos por el usuario se graban en una carpeta creada específicamente para ese usuario y podrían nombrarse con el ID del Usuario (lo cual no es una buena práctica) o con algún UUID o código generado aleatoriamente. La lógica del acceso, en efecto se controla desde la aplicación web, puesto que es un intermediario entre los datos guardados en el servidor y la petición del usuario. Sin importar el lenguaje en el que construyas tu API y/o servidor tendrías que validar:

1. Si los datos de acceso son correctos, guardar la sesión.
2. Verificar el tipo de plan que tiene contratado el usuario y guardarlo en la sesión (o cargarlo a la sesión).
3. La API debe retornar la URL a ese archivo solicitado, en algunas ocasiones puede ser una URL temporal basada en la sesión del usuario. Esto depende de la forma en que lo programes. En este punto es donde se valida no solo si el usuario está logueado, sino también si su plan permite acceso a ese recurso.
4. Si se cierra la sesión, destruir los datos guardados en la sesión.

Esto es algo complejo, piensa en el punto 3. Si el usuario conoce la URL exacta de algún recurso: ¿Podrá el usuario accesar pegando la URL en el navegador sin iniciar sesión? Por ello es que tu servidor debe controlar todas las peticiones.

Un buen ejemplo es EDteam. Si compras un curso puedes tener acceso a ese curso, aunque no tengas el plan premium. Si tienes plan premium puedes tener acceso a todo. Si conoces la URL exacta, puedes ponerla en el navegador, pero el servidor detendrá te negará el acceso porque o no estás logueado o no tienes comprado ese curso o no tienes premium.

En Django por ejemplo existe el Decorador @login_required que justamente solo te permite acceder a una URL si están logueado. Pero esto mismo se puede programar con un conjunto de instrucciones del tipo:

if request.user is None:
   return redirect("/bloqueado")   

If request.user.plan == 1:
   return redirect("/bloqueado")   

O algo así, recuerda que este es solo un ejemplo muy limitado de lo que implica la lógica de control de acceso.

Muchas gracias compañeros por su respuesta, la verdad es que me han ayudado mucho con sus comentarios.

La aplicación estaría construida con Node, Express, Ajax, Websocket y Postgresql.

Ruperto C. Gracias por nombrar la carpeta que se crea específicamente para el usuario, el tío Alexis en un curso nos decía que en la base de datos solo se tendrían que guardar los datos, no imágenes, archivos, pdf, etc... creo que a eso te refieres que sería una mala práctica guardarla en el mismo servidor.

La verdad, es que no sabía que se generaba esa carpeta directamente relacionada con el usuario,(no se prácticamente nada de base de datos) pero me has resuelto totalmente la duda, ya que esa carpeta la guardaré en otro servidor específicamente para guardar ese tipo de datos.

Nuevamente muchas gracias por sus respuestas.

JAMAS ENTENDI ESOS GRAFICOS :V pero entiendo que quieres crear un login con autenticacion la base de datos sql? crea una api con php y la consumes(yo mori en este intento :V) si usas mongodb express nodejs. creo q seria mas facil en

Hola Julio. Normalmente los datos subidos por el usuario se graban en una carpeta creada específicamente para ese usuario y podrían nombrarse con el ID del Usuario (lo cual no es una buena práctica) o con algún UUID o código generado aleatoriamente. La lógica del acceso, en efecto se controla desde la aplicación web, puesto que es un intermediario entre los datos guardados en el servidor y la petición del usuario. Sin importar el lenguaje en el que construyas tu API y/o servidor tendrías que validar:

1. Si los datos de acceso son correctos, guardar la sesión.
2. Verificar el tipo de plan que tiene contratado el usuario y guardarlo en la sesión (o cargarlo a la sesión).
3. La API debe retornar la URL a ese archivo solicitado, en algunas ocasiones puede ser una URL temporal basada en la sesión del usuario. Esto depende de la forma en que lo programes. En este punto es donde se valida no solo si el usuario está logueado, sino también si su plan permite acceso a ese recurso.
4. Si se cierra la sesión, destruir los datos guardados en la sesión.

Esto es algo complejo, piensa en el punto 3. Si el usuario conoce la URL exacta de algún recurso: ¿Podrá el usuario accesar pegando la URL en el navegador sin iniciar sesión? Por ello es que tu servidor debe controlar todas las peticiones.

Un buen ejemplo es EDteam. Si compras un curso puedes tener acceso a ese curso, aunque no tengas el plan premium. Si tienes plan premium puedes tener acceso a todo. Si conoces la URL exacta, puedes ponerla en el navegador, pero el servidor detendrá te negará el acceso porque o no estás logueado o no tienes comprado ese curso o no tienes premium.

En Django por ejemplo existe el Decorador @login_required que justamente solo te permite acceder a una URL si están logueado. Pero esto mismo se puede programar con un conjunto de instrucciones del tipo:

if request.user is None:
   return redirect("/bloqueado")   

If request.user.plan == 1:
   return redirect("/bloqueado")   

O algo así, recuerda que este es solo un ejemplo muy limitado de lo que implica la lógica de control de acceso.

Muchas gracias compañeros por su respuesta, la verdad es que me han ayudado mucho con sus comentarios.

La aplicación estaría construida con Node, Express, Ajax, Websocket y Postgresql.

Ruperto C. Gracias por nombrar la carpeta que se crea específicamente para el usuario, el tío Alexis en un curso nos decía que en la base de datos solo se tendrían que guardar los datos, no imágenes, archivos, pdf, etc... creo que a eso te refieres que sería una mala práctica guardarla en el mismo servidor.

La verdad, es que no sabía que se generaba esa carpeta directamente relacionada con el usuario,(no se prácticamente nada de base de datos) pero me has resuelto totalmente la duda, ya que esa carpeta la guardaré en otro servidor específicamente para guardar ese tipo de datos.

Nuevamente muchas gracias por sus respuestas.