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.