Separate permissions for OPTIONS (for Cordova)
#167 opened on Oct 12, 2017
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:
- Remove permission checking from
OPTIONSaltogether. There are no defaultOPTIONSactions anyway, so any needed permission checking could be done manually when defining a handler (and I'm not sure it'd make sense anyway). - Add an allow/deny rule specific to
optionsjust like we have one forread,insert,write,remove. Presumably then we'd just callcheck_allow_denyforoptionsinstead 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.