You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using ascii_lowercase and string.digits for the scan_id field right now, which does provide us a lot of options but since it's random we have potential to generate collisions. The reason it's only using string. ascii_lowercase + string.digits is because elasticsearch is filtering that token as lowercase. In order to allow scan_id to be case sensitive, we would need to implement a custom elasticsearch filter for scan_id such that it doesn't lowercase all the characters. Then we can add string.ascii_uppercase to our ID character set.
If this can be done entirely programmatically then I'll do it. Otherwise nah.
The text was updated successfully, but these errors were encountered:
I might be able to make the id field for nmap_history a composite key like "id": ip:scan_id which would help fix namespaces and make all scan ids deterministically linked to that ip address. I'm not sure how to do such a key using appropriate types, the id might just have to be a string type.
We are using
ascii_lowercase
andstring.digits
for thescan_id
field right now, which does provide us a lot of options but since it's random we have potential to generate collisions. The reason it's only usingstring. ascii_lowercase + string.digits
is because elasticsearch is filtering that token as lowercase. In order to allowscan_id
to be case sensitive, we would need to implement a custom elasticsearch filter forscan_id
such that it doesn't lowercase all the characters. Then we can addstring.ascii_uppercase
to our ID character set.If this can be done entirely programmatically then I'll do it. Otherwise nah.
The text was updated successfully, but these errors were encountered: