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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-07-29 18:40:19 CEST