Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access Control Middleware on Query Results? #189

Open
curran opened this issue Dec 19, 2017 · 8 comments
Open

Access Control Middleware on Query Results? #189

curran opened this issue Dec 19, 2017 · 8 comments
Labels

Comments

@curran
Copy link
Contributor

curran commented Dec 19, 2017

Is there any way to create ShareDB middleware that inspects and modifies the result from a Query subscription? I'd like to make sure that "private" documents do not leak out from any queries, but I'm not sure how it can be done. Any ideas would be appreciated. Thanks!

@rkstedman
Copy link
Contributor

It sounds like you want to actually modify the query results instead of just blocking certain queries? I'm not sure that's possible - but I do know you can access control the queries. For example, if you wanted to restrict a user to accessing only documents they own (userId is their own userId), you could verify the query the client is submitting matches the userId on the shareDb agent.

backend.use 'query', ({agent, collection, query}, next) ->
   if collection is 'private_docs' && query.userId != agent.custom.userId
      return next('access error')
   return next()

Does that help?

@curran
Copy link
Contributor Author

curran commented Dec 19, 2017

That's interesting. Thank you for your response!

I will see if this approach can work for us.

@rkstedman
Copy link
Contributor

Hey Curran, wanted to follow up - did this solve your issue?

@curran
Copy link
Contributor Author

curran commented Feb 12, 2018

@rkstedman Thanks for following up! Honestly this did not really solve our issue. We have public and private documents in the same collection. We modified our queries to take access control rules into account, so the access control logic needs to be duplicated across all our queries as well as in access control middleware.

Here's an example:

import { DB_DOCUMENTS_PROJECTION } from '../../constants'
import BaseQuerySubscription from './baseQuerySubscription'

// This subscription returns public documents for a given owner
// and documents on which viewer is collaborator.
//
// `owner` is the user id for the user who owns the documents.
// `id` is the user id of the user who is viewing,
//      or empty string if there is no user authenticated.
export default ({owner, id}) => (
  BaseQuerySubscription(       
    {   
      $and: [
        {owner},
        {
          $or: [
            {isPrivate: {$ne: true}},       
            {collaborators: {$elemMatch: {id}}}
          ]
        }
      ] 
    },  
    DB_DOCUMENTS_PROJECTION
  )   
)

It would be great to eliminate the duplicated access control logic around collaborators and public/private, but we haven't found a way yet. Any ideas would be appreciated!

@curran
Copy link
Contributor Author

curran commented Apr 3, 2018

Related to https://github.com/dmapper/server-query

It would be great to have a way for the client to specify a query name and parameters, then have the server fill out the full query. This would eliminate the security vulnerability that comes with allowing clients to specify arbitrary queries.

Any ideas how this could be done?

@balek
Copy link

balek commented Apr 13, 2018

server-query can easily be ported to ShareDB: https://github.com/balek/sharedb-server-query

@curran
Copy link
Contributor Author

curran commented Apr 14, 2018

@balek very cool! Do you have a working example of it? Also, can it be used without Racer? Thank you.

@balek
Copy link

balek commented Apr 14, 2018

Look at the code it's very simple. To use it without Racer simply make ShareDB query in such format: { $queryName: 'some_name', $params: { ... } }. It will be caught and modified with a registered function.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants