search

minvws / nl-kat-coordination

OpenKAT scans networks, finds vulnerabilities and creates accessible reports. It integrates the most widely used network tools and scanning software into a modular framework, accesses external databases such as shodan, and combines the information from all these sources into clear reports. It also includes lots of cat hair.
https://openkat.nl
European Union Public License 1.2
127 stars 58 forks source link

Selecting observed_at date and time and configuring timezone #1960

Open dekkers opened 1 year ago

dekkers commented 1 year ago

There are two related tickets open but those only describe a part of what needs to be done: #581 #967

Functional

Currently we only allow specifying the observed_at date, but it should be possible to specify the date and time. It is also not possible yet to select observed_at on the object detail page and crisis room.

Timezone support should be added to both the displayed datetime and selecting a datetime instead of using UTC everywhere like we do now. Users in an organization could be in different timezones. For reporting the question is if we should use the user timezone or we should add an organization settings to specify a timezone for the organization. If an organization has users in different timezones, it might be confusing if the report timezone is different depending on which user generated the report. If reports are automatically generated using generate_report management command there should also be a way to specify the timezone of such reports.

UX

We currently show the time in the title using @ date, but in my opinion this isn't very clear, especially on the object detail page. The @ syntax is also used in object titles themself. This results in multiple @ in the title of the object detail page of which the firsts are actually part of the title of the object and the last is not part of the object title but the requested valid time.

Technical

There are different options to implement timezone. There isn't a header similar to Accept-Language for timezones, so Django can't know the timezone from a request. You can get the timezone from the browser, but we would need javascript for that. One option might be to have a bit of javascript in the onboarding that let you set the timezone, but this would get outdated when someone travels and changes timezone. Another option might be to always use javascript to show a datetime so we can always use the current browser timezone. We probably should still implement a configuration option to override the browser time.

The datetime-local input element only allows specifying hours and minutes, not seconds, but I think minutes should be granular enough so that shouldn't be a problem.

Most views do multiple calls to get_observed_at. When the value isn't specified it will use the current time, but if we do multiple calls we won't get the exact same datetime back. I think it would be hard to make sure that we only do one call over all views/mixins, so maybe we should change it to an observed_at cached property instead?

If observed_at also has the time, we should fix checks like these where we check if the date isn't in the future: https://github.com/minvws/nl-kat-coordination/blob/main/rocky/rocky/views/ooi_report.py#L49

underdarknl commented 1 week ago

I think we should make the observation time a first class citizen of the url structure and navigation UX.

"When am i looking at" is a request from the user (defaulting to now()) and as such should be driven by the UX when the user makes a choice.

"When was this object last observed, deducted, declared" is a property of the object itself, and should always be the most recent observation, deduction or declaration before the "when am I looking at".

"When did this happen" is the axis we currently don't really deal with, but should, once we reprocess old raw files with new normalizers and bits.

underdarknl commented 1 week ago

N.B. Future deductions could be possible, and useful. Objects that have a known create date in the future (eg, configs), or objects that have a known end date in the future might already trigger new deductions at those dates+1. Knowing which findings will pop up with the current objects, but tested against future policy's stored in configs will give users a very useful heads up of what to prioritize and fix. They could just look at the future date and observe the workload.