A question and probable syntax issue in json-input/json-message maps

[CyberTaoFlow]

Hello,

First I wanted to let you know the username key of the "msapi" pattern within the json-input.map seems to have a leading space.

It is written
" username":".UserId"
Which I believe should be
"username":".UserId"

Second I wanted ask if there is any reason the mappings present in the json-input.map could not also be used in the json-message.map.

I know that for the input map the "software" key is actually used to select the pattern while in the message map it's more of a best match across all fields wins evaluation and the "software" key is ignored. That said I noticed a difference in that currently the input map leverages a newly added feature ("|") to alternate values for a key.

I looked at the source trying to determine if the input and message map both support this alternation using "|" and best I can tell is they use the same set of functions to feed the json parser so yes | should work in either json map?

I tested moving the msapi rules over and it ran but invariably I would end up with a segfault after varying amount of time.

Thanks!

[Deleted user]

Psipher, Thanks for letting me know about the spacing issue in the msapi. That has been resolved. The "input" JSON mapping is the only one that utilizes the "|" (or) field. JSON "message" parsing doesn't support that. You are correct that they are very similar. The biggest difference is with JSON "input" parsing, Sagan already "knows" the JSON template to use via the "software" definition in the sagan.yaml. With JSON "message" parsing, there can be more than one "template" used at a time. Which template to use is determined by a "scoring" mechanism. The idea is that you could "map" fields, even if you are not actively using them, to increase the "score". The best JSON map "score" wins which is what Sagan uses. The idea is that we might be receiving multiple "messages" of various JSON formats. Using "scoring" we can determine what best matches. To be honest, I don't really like the "scoring" mechanism. It's clunky and difficult to use. I think the "input" JSON method works pretty well and is straight forward. I'm working on another project that is strictly a JSON parsing and analysis engine. I'll post more about this project later. It's already working a lot better and is more clear. Lastely, the MS-API rules are meant to be used with the "input" JSON map.... I hope this answered your questions. Let me know if you have any more!

…

On Thu, Jan 14, 2021 at 2:15 PM Psipher Diaz ***@***.***> wrote: Hello, First I wanted to let you know the username key of the "msapi" pattern within the json-input.map seems to have a leading space. It is written " username":".UserId" Which I believe should be "username":".UserId" Second I wanted ask if there is any reason the mappings present in the json-input.map could not also be used in the json-message.map. I know that for the input map the "software" key is actually used to select the pattern while in the message map it's more of a best match across all fields wins evaluation and the "software" key is ignored. That said I noticed a difference in that currently the input map leverages a newly added feature ("|") to alternate values for a key. I looked at the source trying to determine if the input and message map both support this alternation using "|" and best I can tell is they use the same set of functions to feed the json parser so yes | should work in either json map? I tested moving the msapi rules over and it ran but invariably I would end up with a segfault after varying amount of time. Thanks! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEA7UXTYUZXXJ2AZQIMPD2TSZ47ERANCNFSM4WC4UEPQ> .