On Wed, Aug 25, 2021 at 8:52 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Wed, 25 Aug 2021 07:16 +00:00:
> > On Tue, Aug 24, 2021 at 7:03 PM Daniel Shahaf <d...@daniel.shahaf.name>
> > wrote:
> > > Johan Corveleyn wrote on Tue, 24 Aug 2021 15:22 +00:00:
> > > > On Tue, Aug 24, 2021 at 4:45 PM Daniel Shahaf <d...@daniel.shahaf.name>
> > > > wrote:
> > > > > Johan Corveleyn wrote on Tue, 24 Aug 2021 14:25 +00:00:
> > > > > > OTOH, if this kind of behaviour is too far-fetched for a single
> > > > > > subcommand, I might be able to do it by invoking two commands, if I
> > > > > > could succesfully (and invisibly) detect that a cached password is
> > > > > > no
> > > > > > longer correct. As in:
> > > > > >
> > > > > > svn ls --non-interactive $URL >/dev/null
> > > > > > # if exit-code != 0, parse error code to see if it indicates
> > > > > > "auth failed"
> > > > > > if ("auth failed"):
> > > > > > svn auth add $URL
> > > > > >
> > > > >
> > > > > What happens if a valid username/password are cached that have read-
> > > > > only access and one wants to preseed a username/password that have
> > > > > read-
> > > > > write access?
> > > >
> > > > I don't know. We don't have that use case at $company, trying to keep
> > > > things simple :-).
> > > >
> > > > Ah but shouldn't 'svn auth' carry an optional --username parameter? In
> > > > that case, I don't see the problem, I guess.
> > >
> > > My point here is that that pseudocode doesn't handle ensuring that the
> > > cached credentials have read-write access. Existence of «svn auth
> > > --username»
> > > won't change that, because the «svn auth» call is inside an if() block
> > > whose condition will false negative.
> > >
> > > Is there a way to test whether one has rw access without actually doing
> > > a commit or a revprop edit? It's possible with hooks, of course, but is
> > > it also possible without hooks?
> >
> > I'm not sure I understand: why would I need to know that the cached
> > credentials have read-write access?
> >
>
> Your pseudocode detects credentials that have no read access, whether
> for lack of authz or for failing to authn.
Oh? I was assuming that we would be able to discern failed authn (as
in "incorrect username or password") from failed authz (as in "403
Forbidden"). Is that not the case? Do both failed authn and failed
authz yield the same error code / message?
I'm only interested in failed authn, because this entire thread is
about the disabling of the plaintext password cache, and I just want
to know if the cached password is now invalid (with failed authn) so I
have to ask the user for a new one (to potentially use another tool to
inject that new password into the plaintext cache).
> I was asking how to
> generalize this to detecting credentials that successfully authn and
> authz but only for read-only access rather than for full access. That
> would be necessary if the "preseeded" credentials are to be used for
> a write operation (a commit or a revprop edit).
>
> > I only want to verify the authentication part,
>
> This thread is on dev@ as opposed to users@, so I'm trying to solve the
> problem generically, rather than just your specific $WORK scenario.
I get the feeling I'm missing something, but I still don't understand
what authz has to do with the problem at hand here (i.e. detecting
expired passwords so we can ask the user for the new one).
--
Johan
