[pbs-devel] [PATCH backup/proxmox-backup 0/4] fix #5463: add optional consent banner before login

Thomas Lamprecht t.lamprecht at proxmox.com
Thu May 23 14:42:04 CEST 2024


Am 23/05/2024 um 14:10 schrieb Gabriel Goller:
> On 23.05.2024 11:24, Thomas Lamprecht wrote:
>> Anyhow, fine by me, but I then still would prefer having this saved
>> as structured data with an explicit type so that we can easily extend
>> this with an option for actually enforcing such a consent, if ever
>> requested.
>>
>> Maybe we can even add it as encoded text to an existing config, for PVE
>> the datacenter one would be a good fit, for PMG with also have a cluster
>> wide one IIRC and for PBS we could just add it to the node.cfg (and cache
>> inside the http daemon).
> 
> I don't think we will gain much from adding the text in a config file
> here. The config files don't support multi-line values and thus we have to
> escape all the newlines. If we do this, we would have to introduce a ui

Yes, that's why I wrote "as encoded text" ;-)

> textfield where the user can edit the consent file, otherwise he would

Yes, re-using an existing config would allow more easily to expose it on
the UI as we wouldn't have to add new API endpoints managing it, i.e., a
feature.

> have to escape all the newlines manually in the node.cfg file (which is
> a PITA).

For setting it via CLI it would probably best handled as manager CLI
command.

> 
> I am also kind of opposed to a ui element because this is quite a niche
> feature and would only clog the interface.

I do not think the node configuration would get clogged, e.g., on the PBS
UI the Configuration -> Other -> General panel has three rows, and the
rest of that tab panel isn't packed either. Same for PVE's Node -> Options
panel.

Note that in the long run we want to bring every option to the UI sooner
or later. How soon that is depends on mostly from the potential negative
impact, not necessarily how niche that is.

And sure, looking out for the UI not getting to crowded is a good thing,
but the solution there should be to rework the UI to better lay out all
the options and form fields without overwhelming the users, e.g. by using
a different layout, advanced sections, ...

> 
> I don't think an option to strictly enforcing the consent won't come any
> time soon, as it's quite complicated to implement and is mostly used as
> a legal requirement anyway.

My thinking is a bit different here, I would not have thought about adding
this before seeing the feature request including its references to
legislature of one of the biggest countries in the world, so as there
are hundreds of countries, lots of them with their own niche case, I'd
rather make this as extensible as possible from the beginning to avoid
having re-doing it later on for every other countries/agency/... niche
use case.

> 
> Another plus would be that VMWare does the same, so a user would just
> have to come the .txt file /etc/proxmox-backup (+ rename it) and would
> be ready to go.

A reference to how VMWare does would be nice, besides that:
1. copying the message to a text area in the UI or using a CLI tool
   to set that is hardly more work.
2. More importantly, I'd be surprised if these messages are written
   on the spot by an admin on the VMWare host directly, i.e., having
   no other copy. Normally, those things get drafted by a legal
   department, or external counsel, and thus are available from a
   better source of truth than some hypervisor hosts config.

> 
> If we want to add other visual configs such as optional buttons (e.g.:
> "I Accept", "I Decline") I think we should add the in the txt file like
> such (or something similar):
> 
> 	multi-line
> 	text
> 
> 	I Agree|I Disagree|Ignore
> 

So you'd prefer inventing some new brittle domain specific format/parsing
inside a generic text file that users needs to learn and might be turning
complete by accident over using a structured format from the beginning?
Note that with a UI the latter has no real downside (that cannot be
easily disarmed through said UI) but only upsides.





More information about the pbs-devel mailing list