we Developed a panel . so need this.The questions is, what exactly do you want to do? Is it including the noVBNC somewhere or is it just accessing it normally through PVE webinterface?
we Developed a panel wish let more idc company know promox and use promoxwe Developed a panel . so need this.
just now , we have test ok.
this panel forexample whmcs same. sale panel and user center.
whmcs no good. hahaAs said, you need to have a valid ticket and use that to set the "PVEAuthCookie" when requesting the noVNC console.
The ticket can be requested from /access/ticket path, the user requesting the ticket needs to have permissions to see the console for the respective VMs.
If you use a WHCMS module you probably should ask them for help, as they are not made by Proxmox but ModulesGarden/WHCMS (IIRC).
but have a new safe trouble.
if use token login in novnc see vm. guest have get promox login power.
VM.Console
priviledge on the VM/CTs they own, or may use. See https://pve.proxmox.com/pve-docs/chapter-pveum.html#_privilegesso have a question.Yeah sure, that by design. The noVNC console you're using is part of Proxmox VE, if one is logged in in the console they have the same (not more not less) privileges as you assigned them in PVE - so it'd be a bad idea to use an "Administrator" Role for that user
Just give the user which need to access the noVNC console only theVM.Console
priviledge on the VM/CTs they own, or may use. See https://pve.proxmox.com/pve-docs/chapter-pveum.html#_privileges
There is a security issue that I am concerned about.For example, If client A,B,C, each of them have one VM, client A login to the group's NOVNC to access A's VM, at the same time Client A can login to B and C's VMs. So what is the prevention?
ok . tks.A ticket which you give the user must always be privilege restricted, I mean, how else could you restrict the user?
You'd need to have a self-written proxy which translates from your PVE management application access database to PVE itself, but I guess that's more work to get right.
Hi.A ticket which you give the user must always be privilege restricted, I mean, how else could you restrict the user?
You'd need to have a self-written proxy which translates from your PVE management application access database to PVE itself, but I guess that's more work to get right.