Email Create Indicator Fix Plus Sign (+) #607
Conversation
|
Fixes #586 |
…use one side of the relationship exists. However, if both sides of the relationship exists then do nothing.
|
OK so I made another change, while taking a look at issue #586 I ran into the issue where I couldn't create a relationship because I got into a situation where only the "right side" had a relationship (i.e. unidirectional relationship). Just because you have a unidirectional relationship doesn't mean you should fail to create a relationship, just create the other side of the relationship. Anyways, take a look at this, if you decide not to take this specific fix then I have no problem with backing out the change but I will be keeping this fix in my repo. |
|
One last note about the unidirectional relationships... I was able to recreate my issue by very rapidly clicking all 10 plus signs (+) on the email details page. There is some sort of race condition where some of the relationships on the left side are overwritten or are not created, therefore you get the situation where you have a unidirectional relationship from the right side instead of the bidirectional relationship. I'm not going to fix this issue here. |
|
I think it might be better to repair the broken relationship by grabbing the data from the existing half, rather than adding a new half that doesn't match the other half. At least, that's the way I handled it. Thoughts? |
|
Working on a PR already |
The issue was mentioned in crits#607... reason, ind_type passed to handle_indicator_ind() was not using the new vocabulary, and it was bombing out in validate_indicator_value()
|
The indicator_from_header_field() was assigning old IndicatorTypes, I've converted it to the new style Vocabulary, works like a charm. |
|
@brlogan I'm not opposed to copying the data from the other half of the relationship as long as you can assume that half is 'correct' @frbapolkosnik Actually my fix already takes care of this, the client side code passes in the indicator type. The types are already defined in emails/handlers/get_email_detail() in the "email_fields" variable. |
|
The existing half should be the most correct. It will have the analyst that originally formed (attempted to form?) the relationship, and the original date. It may be important to maintain this history, rather than muddying it by having different halves. |
…elationship, copy the found relationship's data to "repair" the missing link.
|
Ok, pushed up some new logic to copy the existing relationship's data if only half of the relationship is found. |
Email Create Indicator Fix Plus Sign (+)
|
Just tested it. All headers worked except reply-to. |
|
Well, trying to add an email address in the form of "Test2 [email protected]" will not work for any of the email address fields. |
|
Because it's not a valid email address. |
|
"Test2 [email protected]" |
|
See PR #612 |
|
Still not a valid address?... |
When on a email details page, clicking the plus sign (+) normally creates an indicator. This was broken because in emails/views.py the indicator types were being set to the following types which are not in the vocabulary anymore. So when you try to create an indicator it complains that it is not a valid indicator type.
I updated the code to use the new vocabulary types by putting the types in the correct locations in the email_details.html template and updating the back end to also grab the new field.
I strongly suggest reviewing the code to make sure nothing is wrong because I haven't done much with the indicator stuff after the removal of STIX/CyBOX.