vsivsi/meteor-file-collection

Separate permissions for OPTIONS (for Cordova)

Open

#167 opened on Oct 12, 2017

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

Repository metrics

Stars
 (158 stars)
PR merge metrics
 (PR metrics pending)

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.

Contributor guide