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.  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.

> 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 :-)).

No one was assuming an incorrect username had been cached.

Reply via email to