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?
I only want to verify the authentication part, and see if the password
that was cached is no longer valid (in which case we need to ask the
new one to the user). I don't really care at this point whether we're
talking about read-only or read-write access, just want to refresh the
password in the cache (for whatever username the user is using ...
it's his business to use the correct username for whatever use case
he's using here :-)).
--
Johan
