and keep the functionality in ResourceTree as generic as possible.
We achieve this by having an 'itemMap' function that can split one item
from the store into multiple to add to the tree.
for the updates, we have to have an 'idMapFn' (to get the original id
back)
we also have to modify how the move checks work a bit, since we only
want to move the items when the tags changed only in the tagview case
in the ResourceGrid we have to get the id a bit differently since we now
have 'virtual' ids for the entries tag contain the tag (which can't be
found in the resource store)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
To hedge against a scenario where an attacker has local or even
physical access to a computer where a user is logged in.
While that general scenario cannot neither get detected nor really
secured against, at least not without requiring re-authentication on
every API call that can have side-effect (i.e., all but GET method),
it still makes sense to ensure that credentials cannot be modified,
which would allow denial of service.
See the related pve-access-control commit 5bcf553 ("user: password
change: require confirmation-password parameter")
Reported-by: Wouter Arts <security@wth-security.nl>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
it seems in new versions of chrome , this triggers too early on a fresh
start (when autostarting a pve tab), resulting in the
'viewWidth'/'viewHeight' being zero pixels. This means we set the width
of the left and the height of the bottom panel to zero pixels, making
them functionally invisible.
To prevent that, check that the 'viewWidth'/'viewHeight' is big enough
so that the panels still have least 50 pixels left before setting their
size.
Reported in the Forum:
https://forum.proxmox.com/threads/136636/
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ TL: point to forum thread ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
by using the delegate function of ExtJS' tooltips on the global
Workspace element and using the proper css selectors
this way, we can limit the tooltips to the non-full ones
(in contrast to using data-qtip on the element, which would
always be show, even for tags with the 'full' style)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Having "Color" added makes it easier to translate (i.e. Farbschema,
配色) and at least as understandable as Theme, so change it,
Suggested-by: Markus Frank <m.frank@proxmox.com>
[ T: while Markus suggested Color Scheme, the hive-mind opted for
this ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the "proxmox-inline-button" class is redundant in the crisp theme as
it only sets the buttons text to black. we mainly use that class for
"help" buttons. this is useful in the dark theme, because we want help
buttons to stand out a bit so (possibly confused) users are drawn to
them more easily. removing the class here doesn't change anything for
"crisp", but makes the dark theme appear more consistent. also fixes
up an unnecessary space.
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
this requires a bump of the widget toolkit so the version includes the
necessary widgets.
Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
This isn't something one will change often, nor it's a core feature
so reduce visibility a bit to avoid that the UI appears more crowded.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
such as the sorting/grouping of guests. saves them in the browser local
storage under 'pve-tree-sorting'
adds a button for it next to the the view selector
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
a new singleton like Utils/Parser, intended for holding stuff for
ui options, such as the tag settings/overrides
no behavioural change intended
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
we got much more wide screens and higher resolutions nowadays than
when this width was decided (before the famous imported from SVN
commit in 2011).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
/cluster/options is now the go to place for getting these options
(until we have more options unrelated to the datacenter.cfg)
Also move the use of the console from VersionInfo to here, since
this will be the future place for ui related backend options.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
in the user menu
we have to make an additional api call here, since it is the only
place (currently) where we can get the realm type
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
[ Thomas: adapt to move of parse_userid to widget-toolkit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
We normally do not stack windows and it breaks/allows some funky
stuff.. As this isn't really required and can be done just fine over
the the DC -> Token panel, especially as we prefill the username to
the logged in one for new tokens now..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if the webinterface got loaded the api call to check if SDN is
available did not yet returned, so we could show it by accident -
even if libpve-network-perl wasn't instralled.
Fix that by hiding it (once) in the failure callback of the API call.
also move menu entries below, before Firewall, this fits better to
networking.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While we nowadays can work much better with package upgrades relating
the cluster stack it still happens that a pve-cluster upgrade can
produce a false-positive 401 (auth failure) code for a currently
valid ticket, e.g., because a pmxcfs lock was requested but the
pmxcfs was currently not mounted due an upgrade triggered restart.
A frequent case for a few false positive 401 is also a cluster
creation, especially if not done over the web GUI.
Thus add a counter, which gets set to 0 on each successful login or
ticket renewal and gets increased on each 401 error. Only show the
logged out window if we get five or more 401 responses. While 5 may
sound a bit much one needs to remember that we always have quite a
few API call in flight (resource update store, stores from current
panel ...) and thus, if one got really auth denied it will still show
quite fast (1 to 5 seconds, depending on which panel is currently
opened). Further, the backend naturally does not allows to do
anything during this time, this has no security implications
whatsoever.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Wit commit a74ba607d4 we switched over
to using the dpkg-dev provided helpers to set package version,
architecture and such in the buildsystem.
But unlike other repositories we used the version also for giving it
back over the API through the during build generated PVE::pvecfg
module, which wasn't fully updated to the new style.
This patch does that, and also cleans up semantics a bit, the
following two changed:
release is now the Debian release, instead of the "package release"
(i.e., the -X part of a full package version).
version is now simply the full (pve-manager) version, e.g., 6.0-1 or
the currently for testing used 6.0-0+1
This allows to do everything we used this information for even in a
slightly easier way (no string concat needed anymore), and fits also
with the terminology we often used in our public channels (mailing
lists, forum, website)
Remove some cruft as we touch things.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Finally make the "Create VM/CT" button distinct from the User
(earlier "Logout") button, this should make them stand out more
As main color the "Proxmox Dark Grey" from our branding guide was
choosen
https://www.proxmox.com/images/proxmox/Proxmox-Corporate-Brandguideline-2018.pdf
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
so we have a more 'web-app' like appearance for the user
the menu contains links to:
* browser localstorage settings
* password change
* tfa change
* logout
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
If we get the cluster name (successful login with '/' Sys.Audit
permissions) then display it in the resource tree's root node.
This updated on login and all ticket refreshs (every 15 minutes).
I currently have no functionallity to refresh it actively on cluster
create over WebUI, as it's not a straight forward change there.
Further, this is something which does not changes often (in
production), and we cannot detect CLI or API triggered (from non-pve
clients) cluster creations anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this is now all in the widget-toolkit and needs to be
set/read to/from there, else we possibly get an inconsistent view on
those
this fixes as issue, where after login the ResourceStore would not update
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Reviewed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
