You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@red-bean.com> on 2010/07/29 16:09:19 UTC
Callbacks, prompts, etc. for issue 2779
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?
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?
--
C. Michael Pilato <cm...@red-bean.com> | http://cmpilato.blogspot.com/
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/29/2010 12:27 PM, Stefan Sperling wrote:
> 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.
Man, I hadn't even previously considered a redirect from http:// to svn://.
Sweeeeeeeeet.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Callbacks, prompts, etc. for issue 2779
Posted by Stefan Sperling <st...@elego.de>.
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
RE: Callbacks, prompts, etc. for issue 2779
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Mike Dixon [mailto:michael.dixon@denovosoftware.com]
> Sent: vrijdag 30 juli 2010 2:55
> To: C. Michael Pilato
> Cc: Subversion Development
> Subject: Re: Callbacks, prompts, etc. for issue 2779
>
> On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
> > On 07/29/2010 12:28 PM, Mark Phippard wrote:
> >> If we just do the redirects, might a user just not perceive SVN as
> being slow?
> >
> > Well, the redirect should be a one-time event. The working copy is
> updated
> > (using svn_client_relocate()) to point to the new, successfully
> contacted
> > URL. From then on, it's business as usually for the working copy.
> It's not
> > like we're constantly following redirects because the working copy
> has never
> > been relocated or anything.
> >
>
> My apologies for jumping in here if I'm misunderstanding the issue, but
> the combination of "HTTP", "redirect" and "one-time event" pushed me
> out
> of passive list-reading mode.
>
> For a 301 redirect, sure, a relocate is appropriate. For other 3xx
> redirects, it may not be. I'm sure you've seen it, but:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
>
> In particular, 302 and 307 are strictly temporary. There's also a note
> in 307 that redirection isn't allowed for anything other than GET or
> HEAD without prompting the user.
>
> It's up to you whether you think it's worth the effort or not, though.
> I
> mean, there's a lot of code out there that doesn't follow protocol
> exactly, and it sounds like always doing a relocate would at least be
> better than the current situation. I just wanted to make sure you
> didn't
> get to the end of your branch and go "oh hey, that's right, there are
> those other redirect codes...".
I think your 'detect if there is really a repository on the other side of the redirect' takes care of this, but we shouldn't forget that many webservers send a redirect on common errors like not-found (404) or server errors (500).
Bert
Re: Callbacks, prompts, etc. for issue 2779
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 30, 2010 at 08:28:06AM -0500, Hyrum K. Wright wrote:
> -Hyrum (who doesn't envy Mike's position of being at the receiving end
> of "design by committee")
I appeal to this commitee to saving Mike from unnecessary complexity!
Let's try not to let the perfect be the enemy of the good.
Subversion ain't a web browser. Let's just punt on temporary redirects,
and ask the humble user to configure their working copy to point to either
a permantly redirecting server, or a server that does not redirect at all.
If no such server exists, the administrator shall be consulted,
and he shall use his unlimited powers to fix the issue.
Recall this part from Mike's last speech, which had a very appropriate
typo in it:
Bug that's would be so intrusive in the codebase as to be impractical
at a minimum, with a tendency towards just plain broken.
We can still improve the behaviour for temporary redirects further,
in a second iteration. The branch as it is right now promises nice
functionality, as long as the problem of security downgrades will also
be dealt with.
Stefan
Re: Callbacks, prompts, etc. for issue 2779
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Fri, Jul 30, 2010 at 7:17 AM, Branko Čibej <br...@xbc.nu> wrote:
> On 30.07.2010 13:57, C. Michael Pilato wrote:
>> On 07/30/2010 03:55 AM, Branko Čibej wrote:
>>
>>> That approach just doesn't sound right to me. I've always understood
>>> that a temporary redirect implies that requests should always try the
>>> original first. Since there's no concept of a session in HTTP, you can't
>>> really assume anything about how long a redirect is valid -- it may be
>>> only for one single request and not for others.
>>>
>> What do you think Subversion should do when it encounters a temporary
>> redirect, then?
>>
> Follow the redirect but not record the new URL in the working copy metadata.
Not being that familiar with the HTTP spec, this would be my gut
instinct as well. I see the analog with a typical web browser here.
When a browser gets a temporary redirect, it redirects, but usually
tries the original location the next time. For a permanent redirect,
a browser will often cache that information and go straight to the new
location. It feels like that's what we should be doing here.
-Hyrum (who doesn't envy Mike's position of being at the receiving end
of "design by committee")
Re: Callbacks, prompts, etc. for issue 2779
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Jul 30, 2010 at 16:17, Branko Čibej <br...@xbc.nu> wrote:
> On 30.07.2010 13:57, C. Michael Pilato wrote:
>> On 07/30/2010 03:55 AM, Branko Čibej wrote:
>>
>>> That approach just doesn't sound right to me. I've always understood
>>> that a temporary redirect implies that requests should always try the
>>> original first. Since there's no concept of a session in HTTP, you can't
>>> really assume anything about how long a redirect is valid -- it may be
>>> only for one single request and not for others.
>>>
>> What do you think Subversion should do when it encounters a temporary
>> redirect, then?
>>
> Follow the redirect but not record the new URL in the working copy metadata.
+1.
--
Ivan Zhakov
VisualSVN Team
Re: Callbacks, prompts, etc. for issue 2779
Posted by Branko Čibej <br...@xbc.nu>.
On 30.07.2010 13:57, C. Michael Pilato wrote:
> On 07/30/2010 03:55 AM, Branko Čibej wrote:
>
>> That approach just doesn't sound right to me. I've always understood
>> that a temporary redirect implies that requests should always try the
>> original first. Since there's no concept of a session in HTTP, you can't
>> really assume anything about how long a redirect is valid -- it may be
>> only for one single request and not for others.
>>
> What do you think Subversion should do when it encounters a temporary
> redirect, then?
>
Follow the redirect but not record the new URL in the working copy metadata.
-- Brane
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/30/2010 03:55 AM, Branko Čibej wrote:
> That approach just doesn't sound right to me. I've always understood
> that a temporary redirect implies that requests should always try the
> original first. Since there's no concept of a session in HTTP, you can't
> really assume anything about how long a redirect is valid -- it may be
> only for one single request and not for others.
What do you think Subversion should do when it encounters a temporary
redirect, then?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Callbacks, prompts, etc. for issue 2779
Posted by Branko Čibej <br...@xbc.nu>.
On 30.07.2010 03:21, C. Michael Pilato wrote:
> On 07/29/2010 08:54 PM, Mike Dixon wrote:
>
>> On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
>>
>>> On 07/29/2010 12:28 PM, Mark Phippard wrote:
>>>
>>>> If we just do the redirects, might a user just not perceive SVN as
>>>> being slow?
>>>>
>>> Well, the redirect should be a one-time event. The working copy is
>>> updated
>>> (using svn_client_relocate()) to point to the new, successfully contacted
>>> URL. From then on, it's business as usually for the working copy.
>>> It's not
>>> like we're constantly following redirects because the working copy has
>>> never
>>> been relocated or anything.
>>>
>>>
>> My apologies for jumping in here if I'm misunderstanding the issue, but
>> the combination of "HTTP", "redirect" and "one-time event" pushed me out
>> of passive list-reading mode.
>>
>> For a 301 redirect, sure, a relocate is appropriate. For other 3xx
>> redirects, it may not be. I'm sure you've seen it, but:
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
>>
>> In particular, 302 and 307 are strictly temporary. There's also a note
>> in 307 that redirection isn't allowed for anything other than GET or
>> HEAD without prompting the user.
>>
>> It's up to you whether you think it's worth the effort or not, though. I
>> mean, there's a lot of code out there that doesn't follow protocol
>> exactly, and it sounds like always doing a relocate would at least be
>> better than the current situation. I just wanted to make sure you didn't
>> get to the end of your branch and go "oh hey, that's right, there are
>> those other redirect codes...".
>>
> Mike, thanks for chiming in. I'm aware of the various redirect codes and
> the permanent/temporary meanings they carry. Today, neither ra_serf nor
> ra_neon recognizes the 307. 301 and 302 are distinguished by different
> error messages (one says "permanently", one says "temporarily").
>
> Technically speaking, we could try to distinguish between 301 and 302/307 by
> allowing Subversion to communicate using the corrected URL while still
> trying to persist the original URL in the working copy. Bug that's would be
> so intrusive in the codebase as to be impractical at a minimum, with a
> tendency towards just plain broken.
>
> Another approach (which has actually been requested of Subversion in the
> past) would be for Subversion to squirrel away the requested URL in the
> event of a 302/307 and remember it as a fallback URL. The request comes
> from folks who want to implement load distribution or DR for their
> Subversion services. Folks always checkout against a generic published URL,
> but the server just redirects them to another specific server URL. If that
> specific URL stops working (the machine goes down or whatever), Subversion
> automatically retries against the squirreled-away original generic URL
> (which perhaps now just redirects them to a different specific URL of a
> machine that's *not* down).
>
That approach just doesn't sound right to me. I've always understood
that a temporary redirect implies that requests should always try the
original first. Since there's no concept of a session in HTTP, you can't
really assume anything about how long a redirect is valid -- it may be
only for one single request and not for others.
-- Brane
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/29/2010 08:54 PM, Mike Dixon wrote:
> On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
>> On 07/29/2010 12:28 PM, Mark Phippard wrote:
>>> If we just do the redirects, might a user just not perceive SVN as
>>> being slow?
>>
>> Well, the redirect should be a one-time event. The working copy is
>> updated
>> (using svn_client_relocate()) to point to the new, successfully contacted
>> URL. From then on, it's business as usually for the working copy.
>> It's not
>> like we're constantly following redirects because the working copy has
>> never
>> been relocated or anything.
>>
>
> My apologies for jumping in here if I'm misunderstanding the issue, but
> the combination of "HTTP", "redirect" and "one-time event" pushed me out
> of passive list-reading mode.
>
> For a 301 redirect, sure, a relocate is appropriate. For other 3xx
> redirects, it may not be. I'm sure you've seen it, but:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
>
> In particular, 302 and 307 are strictly temporary. There's also a note
> in 307 that redirection isn't allowed for anything other than GET or
> HEAD without prompting the user.
>
> It's up to you whether you think it's worth the effort or not, though. I
> mean, there's a lot of code out there that doesn't follow protocol
> exactly, and it sounds like always doing a relocate would at least be
> better than the current situation. I just wanted to make sure you didn't
> get to the end of your branch and go "oh hey, that's right, there are
> those other redirect codes...".
Mike, thanks for chiming in. I'm aware of the various redirect codes and
the permanent/temporary meanings they carry. Today, neither ra_serf nor
ra_neon recognizes the 307. 301 and 302 are distinguished by different
error messages (one says "permanently", one says "temporarily").
Technically speaking, we could try to distinguish between 301 and 302/307 by
allowing Subversion to communicate using the corrected URL while still
trying to persist the original URL in the working copy. Bug that's would be
so intrusive in the codebase as to be impractical at a minimum, with a
tendency towards just plain broken.
Another approach (which has actually been requested of Subversion in the
past) would be for Subversion to squirrel away the requested URL in the
event of a 302/307 and remember it as a fallback URL. The request comes
from folks who want to implement load distribution or DR for their
Subversion services. Folks always checkout against a generic published URL,
but the server just redirects them to another specific server URL. If that
specific URL stops working (the machine goes down or whatever), Subversion
automatically retries against the squirreled-away original generic URL
(which perhaps now just redirects them to a different specific URL of a
machine that's *not* down).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Callbacks, prompts, etc. for issue 2779
Posted by Mike Dixon <mi...@denovosoftware.com>.
On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
> On 07/29/2010 12:28 PM, Mark Phippard wrote:
>> If we just do the redirects, might a user just not perceive SVN as being slow?
>
> Well, the redirect should be a one-time event. The working copy is updated
> (using svn_client_relocate()) to point to the new, successfully contacted
> URL. From then on, it's business as usually for the working copy. It's not
> like we're constantly following redirects because the working copy has never
> been relocated or anything.
>
My apologies for jumping in here if I'm misunderstanding the issue, but
the combination of "HTTP", "redirect" and "one-time event" pushed me out
of passive list-reading mode.
For a 301 redirect, sure, a relocate is appropriate. For other 3xx
redirects, it may not be. I'm sure you've seen it, but:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
In particular, 302 and 307 are strictly temporary. There's also a note
in 307 that redirection isn't allowed for anything other than GET or
HEAD without prompting the user.
It's up to you whether you think it's worth the effort or not, though. I
mean, there's a lot of code out there that doesn't follow protocol
exactly, and it sounds like always doing a relocate would at least be
better than the current situation. I just wanted to make sure you didn't
get to the end of your branch and go "oh hey, that's right, there are
those other redirect codes...".
-Mike
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 07/29/2010 12:28 PM, Mark Phippard wrote:
> On Thu, Jul 29, 2010 at 12:24 PM, C. Michael Pilato
> <cm...@red-bean.com> wrote:
>
>> I was originally thinking "off by default", but only because of the
>> theoretical security implications of being automatically redirected to a URL
>> (possibly a different machine, etc.) that differs from what you expected.
>> Maybe I'm overthinking that, exaggerating the risk? If so -- if there's no
>> risk to automatically following redirection notices -- then is there any
>> value in having either configuration OR prompts for this behavior?
>
> I am just thinking that most people do not plan to need this feature.
> Usually a server moves, or occasionally they enter http instead of
> https and a redirect is in place. If it is not on by default, most
> people are still going to get an error and are unlikely to know to
> turn it on.
>
> If you are a server admin and need to move a server and want to leave
> a redirect behind, we do not give you and tools to also go update all
> your users config's so that they will follow the redirect.
I hear ya. Totally agree.
> If we just do the redirects, might a user just not perceive SVN as being slow?
Well, the redirect should be a one-time event. The working copy is updated
(using svn_client_relocate()) to point to the new, successfully contacted
URL. From then on, it's business as usually for the working copy. It's not
like we're constantly following redirects because the working copy has never
been relocated or anything.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Callbacks, prompts, etc. for issue 2779
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 29, 2010 at 12:24 PM, C. Michael Pilato
<cm...@red-bean.com> wrote:
> I was originally thinking "off by default", but only because of the
> theoretical security implications of being automatically redirected to a URL
> (possibly a different machine, etc.) that differs from what you expected.
> Maybe I'm overthinking that, exaggerating the risk? If so -- if there's no
> risk to automatically following redirection notices -- then is there any
> value in having either configuration OR prompts for this behavior?
I am just thinking that most people do not plan to need this feature.
Usually a server moves, or occasionally they enter http instead of
https and a redirect is in place. If it is not on by default, most
people are still going to get an error and are unlikely to know to
turn it on.
If you are a server admin and need to move a server and want to leave
a redirect behind, we do not give you and tools to also go update all
your users config's so that they will follow the redirect.
I honestly do not know what the security ramifications are. It seems
like browsers automatically follow redirects by default. I agree if
there are no ramifications then the prompts are of less value. The
main value I see in prompts is to let the user know they are being
redirected. Presumably a savvy user will want to use sw --relocate to
avoid these redirects in the future. If we just do the redirects,
might a user just not perceive SVN as being slow?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Callbacks, prompts, etc. for issue 2779
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, Jul 29, 2010 at 11:24 AM, C. Michael Pilato
<cm...@red-bean.com> wrote:
> On 07/29/2010 12:15 PM, Mark Phippard wrote:
>> On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
>> <cm...@red-bean.com> wrote:
>>> 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*
>>
>> My knowledge of the API is from JavaHL. In JavaHL, we have a callback
>> function where SVN can ask a Yes/No question. So I assume this is a
>> callback that already exists in SVN. Could you just use this existing
>> callback (with an appropriately worded Yes/No question)? Not sure
>> that makes it easier or not.
>>
>> If you went with a setting, were you going to propose the redirect
>> feature is on by default? I think it needs to be, else it is not
>> worth doing in the first place.
>
> I was originally thinking "off by default", but only because of the
> theoretical security implications of being automatically redirected to a URL
> (possibly a different machine, etc.) that differs from what you expected.
> Maybe I'm overthinking that, exaggerating the risk? If so -- if there's no
> risk to automatically following redirection notices -- then is there any
> value in having either configuration OR prompts for this behavior?
Also, where does this redirection occur in the order of handling
authn? I would expect a redirect to expire credentials, and to
trigger the prompt for the user to store them.
-Hyrum
Re: Callbacks, prompts, etc. for issue 2779
Posted by "C. Michael Pilato" <cm...@red-bean.com>.
On 07/29/2010 12:15 PM, Mark Phippard wrote:
> On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
> <cm...@red-bean.com> wrote:
>> 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*
>
> My knowledge of the API is from JavaHL. In JavaHL, we have a callback
> function where SVN can ask a Yes/No question. So I assume this is a
> callback that already exists in SVN. Could you just use this existing
> callback (with an appropriately worded Yes/No question)? Not sure
> that makes it easier or not.
>
> If you went with a setting, were you going to propose the redirect
> feature is on by default? I think it needs to be, else it is not
> worth doing in the first place.
I was originally thinking "off by default", but only because of the
theoretical security implications of being automatically redirected to a URL
(possibly a different machine, etc.) that differs from what you expected.
Maybe I'm overthinking that, exaggerating the risk? If so -- if there's no
risk to automatically following redirection notices -- then is there any
value in having either configuration OR prompts for this behavior?
--
C. Michael Pilato <cm...@red-bean.com> | http://cmpilato.blogspot.com/
Re: Callbacks, prompts, etc. for issue 2779
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
<cm...@red-bean.com> wrote:
> 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*
My knowledge of the API is from JavaHL. In JavaHL, we have a callback
function where SVN can ask a Yes/No question. So I assume this is a
callback that already exists in SVN. Could you just use this existing
callback (with an appropriately worded Yes/No question)? Not sure
that makes it easier or not.
If you went with a setting, were you going to propose the redirect
feature is on by default? I think it needs to be, else it is not
worth doing in the first place.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/