#3, #4 and #6 compute scoring, but in case of #3 we need to block the final cart request instead of just increment a score.
WebShiled must compute and update HTTP sessions scores and feed them into Tempesta FW that it can block the overscored sessions.
TBD: basically we need scores for near-real-time operation, so it's impractical to get them from Clickhouse, which gets access logs from batches, since too large delays. Probably this should be done on tfw_logger side tempesta-tech/tempesta#2421 . Also it seems we need to feed the computed scores back to the kernel via an efficient transport
#3, #4 and #6 compute scoring, but in case of #3 we need to block the final cart request instead of just increment a score.
WebShiled must compute and update HTTP sessions scores and feed them into Tempesta FW that it can block the overscored sessions.
TBD: basically we need scores for near-real-time operation, so it's impractical to get them from Clickhouse, which gets access logs from batches, since too large delays. Probably this should be done on
tfw_loggerside tempesta-tech/tempesta#2421 . Also it seems we need to feed the computed scores back to the kernel via an efficient transport