Skip to content

Fix/entities are not optional in maltego transform request message #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
reenberg wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Fix/entities are not optional in maltego transform request message #39

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f18b39c
Removed mandatory=False from entities in MaltegoTransformRequestMessage
reenberg Sep 2, 2014
435cbbb
Removal of dead code and elimination of a bug.
reenberg Sep 3, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions src/canari/maltego/message.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -543,13 +543,12 @@ def __setattr__(self, key, value):


class MaltegoTransformRequestMessage(MaltegoElement):
entities = fields_.List(_Entity, tagname='Entities', required=False)
entities = fields_.List(_Entity, tagname='Entities')
parameters = fields_.Dict(Field, tagname='TransformFields', key='name', required=False)
limits = fields_.Model(Limits, required=False)

def __init__(self, **kwargs):
super(MaltegoTransformRequestMessage, self).__init__(**kwargs)
self._canari_fields = dict([(f.name, f.value) for f in self.entity.fields.values()])

Copy link
Owner

@allfro allfro Sep 4, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line needs to stay in as it provides backwards compatibility to the older Canari API for a MaltegoTransformRequestMessage. If you take a look below, there is a property called fields which provides access to the first input entity's fields.

Copy link
Contributor Author

@reenberg reenberg Sep 5, 2014

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wan't to make sure I understand your argument for backwards compatability.

You are saying that someone might be accessing a private/internal field (as indicated by the leading underscore) of the request message class?
In any case, no one should use private/internal fields, besides the library itself.

Currently I can only think of two possible outcomes for setting this value. In the general case, you instantiate the class with no arguments, in which case it gets a non-entity back from self.entity, which results in self._canari_fields being set to the empty dictionary. Aka in this case the field contains no valuable information anyways.
The other, case is that you give a list of entities as argument to the constructor of the request message. However I can't possibly think of an old solution that is using this way of constructing request messages (as the preferred way of adding entities is with appendelement), and also reading the private/internal (which it should not).

@property
def entity(self):
Expand Down
14 changes: 14 additions & 0 deletions src/canari/xmltools/safedexml-debug/README
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
Copy this folder into path and rename it to safedexml or if you have installed
safedexml from pip, overwrite the dist-packages path
/usr/local/lib/python2.7/dist-packages/safedexml/ with the content.

This will generate some debug output.

It is advised to only copy one of the files at a time (e.g., only __init__.py or
only fields.py) as their output will mingle and it will be near to impossible to
tell them apart. Yest the output is wery simple and could probably have been
made smarter...

Currently the output of __init__.py is the 'best', in the sense that it tries to
nest the output and indent it so, it is easier to follow function calls, and the
'parsing logic' within the parse() function.
Loading