From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pbs-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 576771FF168
for <inbox@lore.proxmox.com>; Tue, 10 Dec 2024 11:36:55 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id F25D513E8D;
Tue, 10 Dec 2024 11:36:59 +0100 (CET)
Date: Tue, 10 Dec 2024 11:36:24 +0100
From: Gabriel Goller <g.goller@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Message-ID: <ijn4ronb2y7peaoj4r25dlknfy6obqifpthkza5wpf7snrfdoa@btipklgcx3ks>
References: <20241206122357.181200-1-g.goller@proxmox.com>
<6762bcfb-a61e-4ad6-a9ed-9d3f882e41ff@proxmox.com>
<pmqzrrr56aucbodbwoddv2n6mfej3xoqnk3msbt5vuwmmkjrps@nguu7jajt4aw>
<imjmi3ksv7quqjopx4wy6qgdtljsarkvbobpdlsne5bqgjhhh4@uwxhilxilzbv>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <imjmi3ksv7quqjopx4wy6qgdtljsarkvbobpdlsne5bqgjhhh4@uwxhilxilzbv>
User-Agent: NeoMutt/20241002-35-39f9a6
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.034 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [PATCH proxmox-backup] ui: add consent banner
maxLength
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
<pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>,
<mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Cc: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: pbs-devel-bounces@lists.proxmox.com
Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com>
On 10.12.2024 11:27, Gabriel Goller wrote:
>On 10.12.2024 11:25, Gabriel Goller wrote:
>>On 09.12.2024 12:29, Thomas Lamprecht wrote:
>>>Am 06.12.24 um 13:23 schrieb Gabriel Goller:
>>>>Add a maxLength of 24000 to the consentBanner. This is the same limit as
>>>>in PVE, and while it makes sense there (file size limits in pmxcfs), it
>>>>acts more as an arbitrary stop-gap here.
>>>>
>>>>Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
>>>>---
>>>>www/config/NodeOptionView.js | 3 +++
>>>>1 file changed, 3 insertions(+)
>>>>
>>>>diff --git a/www/config/NodeOptionView.js b/www/config/NodeOptionView.js
>>>>index c327356f7f24..966e6d719469 100644
>>>>--- a/www/config/NodeOptionView.js
>>>>+++ b/www/config/NodeOptionView.js
>>>>@@ -59,6 +59,9 @@ Ext.define('PBS.NodeOptionView', {
>>>> name: 'consent-text',
>>>> text: gettext('Consent Text'),
>>>> deleteEmpty: true,
>>>>+ fieldOpts: {
>>>>+ maxLength: 24000,
>>>
>>>But that's frontend only? So not really a limitation for anybody.
>>>While it is great to have for UX, the real check should go into
>>>the backend.
>>
>>Right, I'll add a limit to the api as well.
>>Note that we also have a request body size limit
>>(proxmox-rest-server/src/rest.rs:409), which I think is quite sensible,
>>so I'd set the frontend limit to the request body limit -1024 (for other
>>options to coexist) (so 63 * 1024) and I'll set the backend limit to
>>128kB that you suggested.
>
>No I'm stupid that won't help anything.
>I'll have to set the backend limit when updating to the 63*1024 as well.
>I could set a limit when reading though, but that seems a bit harsh.
Actually the schema does this already. So when setting max_length in the
schema reading and writing above that length fails. Obviously when a
user manually inputs something longer, a few panels in the ui won't
work, but the error message there is quite understandable. Optionally I
could check the length in the validate method that is only checked when
saving new data. But that still allows the user to manually paste
something in the file.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel