On 07/29/2010 12:27 PM, Stefan Sperling wrote: > Allowing N redirects by default, and when N is reached printing a message > saying that people can raise or lower the number of allowed relocation > attempts from the configuration file sounds fine. > > In case a client ends up being mis-redirected, people should also be > told in this message that svn switch --relocate is the way to set the > correct URL.
The case of misdirection *shouldn't* be an issue. The code does this redirection when trying to open an RA session, and ultimately requires that the RA session was successfully opened *and to a repository that matches the original expected repos UUID*. If the redirection sends the client off to a non-repos or to a different repos, the you'll see a notification that the client is following a redirect and then a failure of the "this ain't a repos" or "repos UUID mismatch" variety. > BTW, can the client end up being redirected from a https:// URL to > a http:// URL, or to an svn:// or svn+ssh:// URL? If we decide not > to prompt, we should not allow URLs to be downgraded to less secure > schemes. And even if we do prompt we should print a huge warning in > large friendly letters if going from https:// to http://, for instance. The redirection logic doesn't care what the "corrected URL" is today. So you can be redirected from any http:// or https:// URL to any http://, https://, svn*://, ... or heck, even a file:// destination. I hadn't considered the "security downgrade" issue at all. Hrm... > If we follow the prompting approach, maybe it's time to add a generic > callback prompting interface. > > For instance, the "Do you want to store passwords in plaintext? [yes/no] " > prompt uses its own special callback type. Now you'd need to add a similar > callback type to ask a different question, also expecting a yes/no answer. > > Adding another callback type for this feels wrong. We shouldn't be > forced to rev APIs whenever the need to ask a new question arises. > So what about adding a general prompting interface to the 1.7 APIs and > also upgrade the password prompt to use it? If you're going to add a *generic* prompting mechanism, then don't add it to *specific* APIs at all -- toss it into the client context. I do think that any such thing would need to accept an enum that uniquely reveals the type of question being asked so that clients can choose to suppress or auto-answer certain types of prompts, but that's not so difficult. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
