zorba-coders team mailing list archive

[Chris Hillery <988417@xxxxxxxxxxxxxxxxxx>]

I saw the branch merge proposal before I noticed this bug, so I'll copy
my comment from there:

I don't like that this mechanism is so different to the way you block
non-internal modules (using a URIMapper with DENY_ACCESS). While it
would be a bit less efficient, it would be more consistent to call
static_context::resolve_uri() at translator.cpp line 2840 solely for the
purpose of seeing if zerr::ZXQP0029_URI_ACCESS_DENIED is thrown.

Further note:

Actually it would be sufficient to call
static_context::apply_uri_mappers() if we made that method non-private,
or (probably better) added a method static_context::get_candidate_uris()
which was exactly the same as static_context::get_component_uris()
except for passing internal::URIMapper::CANDIDATE instead of COMPONENT.

-- 
You received this bug notification because you are a member of Zorba
Coders, which is the registrant for Zorba.
https://bugs.launchpad.net/bugs/988417

Title:
  block internal modules

Status in Zorba - The XQuery Processor:
  New

Bug description:
  If one wants to limit the choice of of available modules for a user,
  this is very easy for external modules. One simply registers an
  URIMapper that disallows access to certain modules. However, this does
  not work for Zorba's internal modules as those are not resolved via
  the usual resolution mechanism.

To manage notifications about this bug go to:
https://bugs.launchpad.net/zorba/+bug/988417/+subscriptions