On Thu, Jul 29, 2010 at 12:09:19PM -0400, C. Michael Pilato wrote:
> Fer yer reference: http://subversion.tigris.org/issues/show_bug.cgi?id=2779
>
> I've got Subversion on the issue-2779-dev branch able to follow redirects
> from the server without user verification, with a hard-coded limit as to the
> number of hops to follow before quitting, and with notification to the
> client that the (or, each) redirection has occurred. I don't like the
> hard-coded limit, and I don't like the hard-coded decision to always follow
> redirects at all.
>
> My original plan to add a ~/.subversion/servers configuration bit for
> whether or not to honor server redirects. In fact, I could fix both of my
> "don't likes" above by naming the flag max-redirects and giving it a numeric
> value (0 means don't follow, other positive integers serve to allow with
> limits the automatic redirection).
>
> However, it was suggested that the client actually prompt the user when such
> an event occurs for what to do.
>
> I'm not fully sold on one approach or another, but I'm wondering two things:
>
> a) What do folks think about the various approaches?
I'm not sure which I like better.
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.
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.
> b) If the prompting approach is preferred, what's a reasonable way to do
> this? The notification function cannot serve as a prompt. We could add a
> redirection_callback_func to the likes of svn_client_update,
> svn_client_checkout, svn_client_switch, svn_client_relocate, etc., but that
> seems like such a really weird concept to expose at the API level. We could
> introduce a custom prompting function in the client context baton. *shrug*
> Got suggestions?
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?
I'd be inclined to help you with this, especially the part of making
the password prompt use the generic prompt callback. We could do this
on trunk, and then you can use it on the branch. Your call.
Stefan
Received on 2010-07-29 18:28:08 CEST