vsivsi/meteor-file-collection

Separate permissions for OPTIONS (for Cordova)

Open

#167 aberto em 12 de out. de 2017

Ver no GitHub
 (3 comments) (0 reactions) (0 assignees)CoffeeScript (38 forks)github user discovery
enhancementhelp wanted

Métricas do repositório

Stars
 (158 stars)
Métricas de merge de PR
 (Métricas PR pendentes)

Description

I just got meteor-file-collection working on Android via Cordova, but I ran into an issue that could use some tweaks to these lines:

                     when 'OPTIONS'  # Should there be a permission for options?
                        unless (share.check_allow_deny.bind(@)('read', req.meteorUserId, req.gridFS) or
                                share.check_allow_deny.bind(@)('write', req.meteorUserId, req.gridFS) or
                                share.check_allow_deny.bind(@)('remove', req.meteorUserId, req.gridFS))

My conclusion is that the answer to # Should there be a permission for options? is essentially "no". The issue is that the browser triggers a preflighted request without sending the X-Auth-Token cookie (as claimed here and verified by extensive experiments). Thus I need to allow OPTIONS requests from everyone, without authorization, just to tell the browser "yes send your credentials". But I don't want to change my read, write, remove allow rules which do actual authentication once I have the X-Auth-Token.

I see two options:

  1. Remove permission checking from OPTIONS altogether. There are no default OPTIONS actions anyway, so any needed permission checking could be done manually when defining a handler (and I'm not sure it'd make sense anyway).
  2. Add an allow/deny rule specific to options just like we have one for read, insert, write, remove. Presumably then we'd just call check_allow_deny for options instead of or-ing them all together, but I don't really care either way.

Happy to put together a PR once you decide which option you'd like.

Guia do colaborador