instead of relying that the authorization URLs and the ordered
identifiers are sorted the same way for already validated
authorizations.
on the contrary, RFC 8555 even says:
"The authorizations required are dictated by server policy; there may
not be a 1:1 relationship between the order identifiers and the
authorizations required."
authorizations MUST always include a single identifier, no matter which
state they are in.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
mixed bag of improvements:
- return hash based on domain
- check for duplicate domains, allow overlap between main and additional
keys otherwise
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
With this configuration it is possible to use many different plugins
with different providers and users.
Signed-off-by: Wolfgang Link <w.link@proxmox.com>
Allow additional domains with different sub-plugins,
However, only one domain per additional entry is permitted.
Signed-off-by: Wolfgang Link <w.link@proxmox.com>
exact same thing commit 67cb91e4d7
already did for the old location of this, but indentation error was
introduced again when moving it (fix y'all editors..)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
opens a window with the parameters for the sync and two buttons:
'preview' and 'sync'
both open the taskviewer, but the 'preview' one sets the 'dry-run'
parameter so that it does not get written out to the user.cfg
loads the realm config and prefills the selection with values from
the config, and shows a hint about where to set the defaults
if none are set
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
All local disks can/will be migrated if not for a reason we don't
know about yet at this stage. The disks we get from the API call as
'local_disks' are either referenced by the config or by snapshots in
the config (which was not checked for and the reason one could run
into the 'else if' branch).
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if our self-signed certificate expires in more than 825 days, but was
created after July 2019 it won't be accepted by modern Apple devices. we
fixed the issuance to generate shorter-lived certificates in November
2019, this cleans up the existing ones to fix this and similar future
issues.
two years / 730 days as cut-off was chosen since it's our new maximum
self-signed certificate lifetime, and should thus catch all old-style
certificates.
another positive side-effect is that we can now phase out support for
older certificates faster, e.g. if we want to move to bigger keys,
different signature algorithms, or anything else in that direction.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this modifies AuthEditBase so that if there is a sync inputpanel specified,
we display it in a second tab (we need to modify the bodyPadding here,
else the whole window has too much padding)
we use the same panel for both ldap/ad, since the most options behave
the same (except for user_attribute, but the default for AD is
sAMAccount which i think is good enough for now, users can still
override it in the cli)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
that breaks the schema as the POST endpoint obviously doesn't knows
about a delete property.
fixes commit 58e1ccc4f5
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
if 'delete' is an Array, we want to push into it, not append a string
this could be an issue when we use an edit window with multiple inputpanels
and deleteEmpty set on some fields
we then could have an aray like this:
values: {
delete: [
'foo',
'bar',
'baz, qux',
],
},
which the edit window does not handle correctly anymore
(it only does string splitting if 'delete' itself is a string)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
similar to storage/Base.js so that we have the different
RealmTypes in different inputpanels
this will come in handy when we define sync options
Signed-off-by: Dominik Csapak <d.csapak@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>
