Mentat

Latest patch replaces information icon about reaching limit with clickable load button, that enables users fetch not yet fetched data on demand.

You may try it here:

https://mentat-alt.cesnet.cz/mentat/events/a86158e5-bfab-4633-bc5f-7099cbf71eb8/show

In case of weird behavior make sure to load fresh JavaScript files by opening developer console and reloading the page.

Pavel Kácha wrote:

Very coool. Appreciate the work that went into it. Limit for number of items is per IP or per queried service?

Limit is set for (Source/Target).IP, current value is 10. Data services may register hooks for object types they are capable of handling (IP4/6,hostname,...). Additional data are then fetched from all registered services for that type. For example in case an IDEA message has 15 Source.IP4s, it will result in 10x5 API queries because there are 5 services registered to handle IP4s. If there are any Target.IP4, they will have separate limit counter. The idea behind this is to resolve some number for each object type, but not to overwhelm the service APIs.

Also, some reasonable caching would make sense (shall I make new issue?)

Yes, that is absolutely necessary before releasing it to production. There is no need for a new issue in my opinion.

Jan Mach wrote:

Pavel Kácha wrote:

Very coool. Appreciate the work that went into it. Limit for number of items is per IP or per queried service?

Limit is set for (Source/Target).IP, current value is 10. Data services may register hooks for object types they are capable of handling (IP4/6,hostname,...). Additional data are then fetched from all registered services for that type. For example in case an IDEA message has 15 Source.IP4s, it will result in 10x5 API queries because there are 5 services registered to handle IP4s. If there are any Target.IP4, they will have separate limit counter. The idea behind this is to resolve some number for each object type, but not to overwhelm the service APIs.

Ok, makes sense.

Also, some reasonable caching would make sense (shall I make new issue?)

Yes, that is absolutely necessary before releasing it to production. There is no need for a new issue in my opinion.

Ack. Thx.

Seems to me Targets don't get info from DNS/PassiveDNS, that's intentional?

Pavel Kácha wrote:

Jan Mach wrote:

Pavel Kácha wrote:

Very coool. Appreciate the work that went into it. Limit for number of items is per IP or per queried service?

Limit is set for (Source/Target).IP, current value is 10. Data services may register hooks for object types they are capable of handling (IP4/6,hostname,...). Additional data are then fetched from all registered services for that type. For example in case an IDEA message has 15 Source.IP4s, it will result in 10x5 API queries because there are 5 services registered to handle IP4s. If there are any Target.IP4, they will have separate limit counter. The idea behind this is to resolve some number for each object type, but not to overwhelm the service APIs.

Ok, makes sense.

Also, some reasonable caching would make sense (shall I make new issue?)

Yes, that is absolutely necessary before releasing it to production. There is no need for a new issue in my opinion.

Ack. Thx.

Seems to me Targets don't get info from DNS/PassiveDNS, that's intentional?

They do, there is just an empty result. You can see for yourself by opening the developer console and checking console logs. All services are queried for all objects except for NERD, which does not support IPv6.

Jan Mach wrote:

Pavel Kácha wrote:

Seems to me Targets don't get info from DNS/PassiveDNS, that's intentional?

They do, there is just an empty result. You can see for yourself by opening the developer console and checking console logs. All services are queried for all objects except for NERD, which does not support IPv6.

Mmmkay, my bad.