Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Access thoughts

Abierto
  • ¿Algo no está bien?
#10 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
javascript
Área
authorization

Línea de trabajo

Empieza leyendo el servidor de rutas existente y el callback de acceso por modelo, incluido el modelo de acceso BCLC mencionado en la discusión. Compara las comprobaciones basadas en rutas y basadas en recursos y, después, define qué debe hacer la API de middleware y cómo interactúan la carga, las comprobaciones de acceso y el enrutamiento de la API. Se considera terminado cuando los enfoques de acceso en competencia se hayan reconciliado y se haya acordado el comportamiento previsto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Adrian Rossouw: so yh, kkaefer :
Adrian Rossouw: regarding the access stuff
Adrian Rossouw: how about allowing this :
Adrian Rossouw:             acl['/api/Project*'] = function(req) {} ;

yh: heh
eric left the room (Replaced by new connection).
eric [[email protected]/Eric-Gundersens-MacBook-Pro] entered the room.
yh: Adrian Rossouw: i like the direction, i wonder if we can even just have it match the router API
yh: e.g. if there is a req.session.user, an access middleware basically pipes through the user model's access route middleware or so
Adrian Rossouw: yeah
Adrian Rossouw: it's kind of already happening
yh: yeah, just in a one-off kind of way
Adrian Rossouw: with the tilestream one. 
yh: Adrian Rossouw: right, ideally the api would look a lot more like express though
yh: e.g. you get some kind fo access router object and you do
Adrian Rossouw: would that happen during init ?
yh: access.get('/api/Project*', function(req, res, next) {});
access.post('/api/Foo*', function(req, res, next) {});
etc.
Adrian Rossouw: yeah
yh: yeah i'm not sure
Adrian Rossouw: also
Adrian Rossouw: we cant do anything that needs to happen asynchronously
yh: right, it's assumed that any crud loading is done prior to the access router
Adrian Rossouw: yeah
Alex: yh: the problem with 

access.get('/api/Project*', function(req, res, next) {});
access.post('/api/Foo*', function(req, res, next) {});
Adrian Rossouw: which is why i had to implement the email check in a server
Alex: is that you'l wind up calling access checks for collections on models
Adrian Rossouw: i dont understand why alex 
Adrian Rossouw: the access check is in the Route server
Alex: i think we have two fundamentally different ways of checking access here and both have a pretty good justification…. i wonder to what extent we need to reconcile them. one is path based, the other one is resource based
Adrian Rossouw: alex: resource based would always run
eric left the room (Replaced by new connection).
eric [[email protected]/Eric-Gundersens-MacBook-Pro] entered the room.
yh: Alex: the idea is that the resource here is coming in on the req object
yh: like in your example
Alex: right
yh: you could do the same logic with access.get('*', [check req.model for whatever you want here]) if you wanted
Alex: right, or with middleware
Adrian Rossouw: well. the pattern seems to be middleware that asks the loaded model
Alex: which i'd prefer… i just don't see why we would apply such access checks only for specific routes
Alex: (such access checks = model specific access checks)
Adrian Rossouw: not just
Adrian Rossouw: alex: like protecting the Search endpoints
Adrian Rossouw: maybe what we need is to break up the route middleware
Adrian Rossouw: i see we've basically copied it into bclc
yh: ok so the stack i'm seeing here is something like

-> auth server (adds user model to session)
-> load server (loads models, other objects)
-> access server (if user model is present, calls its access middleware stack)
-> api route server (like the current route server)
Adrian Rossouw: so have it be 'loadmodel' , [access check] , 'doStuff'
yh: it basically means splitting the route server into a load / route servers that can sandwich an access server in between
yh: yeah
Adrian Rossouw: yeah
yh: so for BCLC let's just leave the access model as is? (using the per-model access callback)
Adrian Rossouw: one distinction here yh, is they want the access rules to be on the accessed object
Adrian Rossouw: yh: the issue is we have both at present
Adrian Rossouw: and they conflict
Alex: yh: we'll have to do some reconciling, but yeah, i want to leave it as is
Alex: and see how that flies
yh: yeah, why do you want to have the access rules on the model?
Alex: yh: so here's why:
yh: i don't quite understand that
Alex: you need a lot of inside knowledge about your model
Alex: so you'll either write these rules into your model
yh: oh
Alex: or somewhere where it's ok to have a lot of knowledge about your model
yh: ok yeah
Alex: that 'somewhere' is not quite clear what that would be
yh: i think it's fine i just don't think the access method on the model should be request-interfacing
Alex: it's the model, the route, the view  or the countroller
Adrian Rossouw: one point alex, i still feel the access should be a method, and not an object
yh: e.g. it's weird to me that the model method should look for req.session.user
Adrian Rossouw: because it's the only present way to clean inheritance 
Alex: yh: but that's the point, you need that request too, right?
Alex: yh: yeah
yh: Alex: right, but with the system above you could do
Alex: i'm sharing these feelings
yh: access.get('*', function(req, res, next) {
  // pass the user to the model or so
  req.model.access(req.session.user);
})
yh: like you could basically come up with whatever access method system you want on your models
Adrian Rossouw: i would also put the access methods Model.server.bones
Lenguaje dominante
JavaScript
Estrellas
17
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de developmentseed/bones-auth

Todos los issues de developmentseed/bones-auth

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.