On Wed, Oct 19, 2022 at 1:05 AM Arne Schwabe wrote:
>
>
> If we can conjure up usernames (like with empty --> token-user) why not
> allow other username
> changes too?
>
> In general the current authentication system in OpenVPN is ill equipped to
> handle them. On renegotiation we only do auth
Am 19.10.2022 um 01:01 schrieb Selva Nair:
Hi,
On Mon, Oct 10, 2022 at 3:14 AM Gert Doering wrote:
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of
Hi,
On Mon, Oct 10, 2022 at 3:14 AM Gert Doering wrote:
> We do not permit username changes on renegotiation (= username is
> "locked" after successful initial authentication).
>
> Unfortunately the way this is written this gets in the way of using
> auth-user-pass-optional + pushing
Hi,
On Mon, Oct 10, 2022 at 10:00:37AM +0200, Antonio Quartulli wrote:
> > -if (username)
> > +if (username && *username)
>
> super uber nitpick (bike shadding level):
>
> I think in other places we perform the very same check using the format:
> username[0] instead of
Hi,
On 10/10/2022 09:12, Gert Doering wrote:
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of using
auth-user-pass-optional + pushing "auth-token-user" from
We do not permit username changes on renegotiation (= username is
"locked" after successful initial authentication).
Unfortunately the way this is written this gets in the way of using
auth-user-pass-optional + pushing "auth-token-user" from client-connect
(and most likely also "from management")
