Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Access thoughts

Đang mở
  • Có gì không ổn?
#10 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
javascript
Lĩnh vực
authorization

Hướng nghiên cứu

Bắt đầu bằng cách đọc route server hiện có và access callback theo từng model, bao gồm access model BCLC được đề cập trong phần thảo luận. So sánh các kiểm tra dựa trên path và dựa trên resource, sau đó xác định middleware API cần thực hiện gì và loading, các kiểm tra access cũng như API routing tương tác với nhau như thế nào. Công việc được xem là hoàn tất khi các cách tiếp cận access cạnh tranh đã được dung hòa và behavior dự kiến đã được thống nhất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
JavaScript
Star
17
Fork
1
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của developmentseed/bones-auth

Tất cả issue của developmentseed/bones-auth

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.