BIND 10 #473: ModuleCCSession only validates config data, not commands
BIND 10 Development
do-not-reply at isc.org
Fri Jan 7 16:35:31 UTC 2011
#473: ModuleCCSession only validates config data, not commands
-------------------------------------+-------------------------------------
Reporter: jelte | Owner: jinmei
Type: | Status: reviewing
enhancement | Milestone:
Priority: major | Resolution:
Component: | Sensitive: 0
configuration | Add Hours to Ticket: 0
Keywords: | Total Hours: 0
Estimated Number of Hours: 2.0 |
Billable?: 1 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => jinmei
Comment:
proposed changelog:
[bug] Jelte
Command arguments were not validated internally against their
specifications. This change fixes that.
(comments left out were taken over and fixed)
Replying to [comment:3 jinmei]:
> '''General comments'''
> - how about the python part? shouldn't we validate commands in
> ccsession.py, too? Note, however, that xfrin and zonemgr (and
> perhaps others) depend on "hidden" commands not listed in the
> formal spec. anyway, if we want to validate commands in python,
> too, I think it should go to a separate ticket.
>
Yes, I think it was proposed a while ago to add the optional flag
'public' (or otherway around, 'hidden') to commands, i.e. hide
commands that are in the specification to user interfaces. If we have
that we can add this there as well.
> '''ccsession.cc'''
> - parseCommand
> - (not related to this change) is the comment above the function
> still valid? it seems that if the given 'command' doesn't look like
> a command it throws an exception. in any case, IMO this
> description (with correction if necessary) should be merged in the
> description in the header file.
ohright, well removed it in favour of the now slightly modified
documentation in ccsession.h
> - ModuleCCSession::checkCommand()
> - should the new logic move to a separate function, e.g.,
> handleCommand()? this is largely a matter of preference, but due
> to the additional logic checkCommand() now looks quite long, and
> mostly beyond an understandable level at a glance.
Yeah it was at about the limit :) Split it up, added two private
methods checkConfigUpdateCommand, and checkModuleCommand
> - I hate to see a magic number:-) What is this "3"? (in that sense
> I don't like the hardcoded "1" below this line, either)
> {{{
> answer = createAnswer(3, ss.str());
> }}}
>
Any value that is not zero :)
(yes we should formalize this and make a list of errors that can occur
in internal messages that expect responses, but i think that is more
general than just this and deserves its own ticket)
> '''ccsession.h'''
> - (not directly related to this change) I think the description could
> be more detailed. for example, an example would be useful. I'd
> also to know which exceptions can be thrown, if any (and there are
> some, actually).
You mean for the entire class? I'll do that separately then (so we can
progress this ticket).
>
> '''module_spec.cc (): ModuleSpec::validate_command()'''
> - validate_command() should be named validateCommand() according to
> the guideline
ack, there were more of those :p Fixed those as well.
--
Ticket URL: <http://bind10.isc.org/ticket/473#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list