Current error message is not correct because having underscores in
domain names are perfectly valid, although it's not acceptable at host
names, so it should be changed to "This is not a valid hostname".
https://www.ietf.org/rfc/rfc1123.txt section 2.1 "Host Names and Numbers"
https://www.rfc-editor.org/rfc/rfc2181#section-11
Signed-off-by: Amin Vakil <info@aminvakil.com>
[TL: s/Host /host/ once more, reflow msg with 70cc & reword subject]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Overrides 'Ext.util.Cookies', optionally allowing the SameSite
attribute of cookies to be defined. Using this override, the SameSite
attribute of the auth cookie is now set to 'strict', prohibiting the
cookie from being sent along in cross-site sub-requests or when the
user navigates to a different site.
Signed-off-by: Max Carrara <m.carrara@proxmox.com>
JsonSchema is already ok:
$CONFIGID_RE = qr/[a-z][a-z0-9_-]+/i;
This is blocking creation of snapshot name with "-" in gui.
(works fine command line)
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Regex parses a cpuset via 2 matches. Find number(s) or range(s) folowed
by a comma, then, find a single number or a single range not followed
by a comma. E.g., 0-1,4-5,6,7,10,11,14-15
CpuSet function first checks regex, then ensures left num <= right num
Signed-off-by: Daniel Bowder <daniel@bowdernet.com>
`proxmoxMail` used its own regex pattern to validate emails. that
meant certain email addresses were rejected by the front-end that
were accepted by the backend that uses the functionality from
`pve-common`. examples include the following:
- "user@host.test-tld"
- "user-@host.testtld"
- "user@host"
reported on the forum: https://forum.proxmox.com/threads/gui-bugulance-using-the-user-add-gui-interface.114743/
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
When the up or down arrow key on the keyboard was pressed while a
number text field (or any one descending from Ext.form.field.Spinner)
was selected, the up and down callbacks for that text fields KeyNav
were called twice. Therefore, the value in the text field would always
incorrectly increment/decrement by step * 2.
The problem was an overwrite for the onRender() method of the Spinner
class, which caused the callbacks for pressing an arrow key to be
registered for a second time. Simply not doing that in the overwritten
onRender() method fixes the problem.
The redundant declarations for spinUpEl and spinDownEl were removed as
well. Additionally, the 'mousewheel' event handler, registered in the
overwritten (but still executed) parent function, is unregistered now,
as it could lead to unintended side effects in browsers which still
implement this event.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
some devices (e.g. vms via novnc, and some laptops) get the pointerType
'pen' under chromium.
the DragZone handler tries to ignore touch input for that by
checking for "=== 'mouse'" which does not include 'pen'
so override that to handle it when the pointerType !== 'touch'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
found with `codespell`, mostly comments but also a fn parameter and
an error in an exception message
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
not all users of Toolkit.js have the charts lib loaded, which means
the class does not exist then.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
seems to be fixed, at least i could not reproduce here.
If users report this again, we can still revert it if necessary.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
while some scrolling issues where fixed since 6.0.1, some where introduced,
namely:
* for firefox, the correct event to listen to is 'wheel' not 'mousewheel'
* the spinner scroll direction was incorrect
* the boxOverflow scroll direction was incorrect
* the boxOverflow scroll amount was too high
functions were copied from extjs source, eslintified, and adapted
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
instead of the upstream default of 'async'
we do this since it creates some problems with our callbacks which can
happen during component destruction. The upstream reasoning does not
really makes sense for us normally, since we do not keep any references
around for most things, and thus the garbage collector can claim it.
note that this is only for components, Ext.Base sets it to 'true' by
default and we do not change this since we normally do not extend
from non-components
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
ExtJS email validation regex has a length limit of 6 on the TLD.
This breaks some new gTLDs (e.g. .systems)
Override the validation function and verify against the EMAILRE from
PVE::Tools (used for 'e-mail' in JSONSchema)
Reported in our community forum:
https://forum.proxmox.com/threads/acme-account-register-dialog-does-not-accept-gtlds.87305/
Quickly tested (by using test@test.systems(|test)? on my test-installation)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
After the UI hang for tens of seconds for a few thousand elements got
deselected I investigated with Firefox developer tools performance
analysis, where the waterfall view showed that most of the time was
spent in array splicing.
Previously, all removed elements got removed on by one from the
`selected` Ext.util.Collection - which is basically an helper class
around arrays and objects, most of it may have become obsolete with
modern browsers. The single remove resulted into further splicing of
the array, and all in all it resulted in a dramatically increased
complexity, ~ O(n^3).
The "remove one by one" logic comes highly probably from the fact
that users can register a `beforedeselection` listener which can
block a removal of a specific record. But, that's not used by us and
not really something one would often need in practice, but still its
a documented feature of ExtJS grids we want to keep; so go for an
alternative.
So, override `doDeselect` and change the old removal logic to one
that first record those entries which got blocked from removal and
remove them in one go from the "to-be-removed" collection.
Before/After this patch on my FF 86.0.1 with my i9-9900K and
deselecting ~10k records went from ~40s to about 33 ms total, so for
that case we went 1000x faster.
The remaining time is now mostly spend in the event fire/handling
logic, but even with 50k records we spent <<500ms in total, so not
too bad and thus kept as is for now.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-By: Dominik Csapak <d.csapak@proxmox.com>
Tested-By: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-By: Stoiko Ivanov <s.ivanov@proxmox.com>
when using the mode 'MULTI' for the checkbox selection model,
clicking a row would deselect all others, only clicking exactly on the
checkbox would select multiple rows
this override makes the whole cell of the checkbox behave like the
checkbox. This minimizes misclicks from the user.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
