You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Konstantin Kolosovsky <Ko...@jetbrains.com> on 2013/08/05 12:14:31 UTC
Subversion 1.8 "--non-interactive" and "--force-interactive" flags
behavior
Hi Everyone,
I've got a question about "--non-interactive" and "--force-interactive"
flags behavior in Subversion 1.8.
I'm not subscribed to the mailing list, please put my email in Cc in any
responses.
We've got java application interacting with svn.exe command line
utility. For Subversion 1.7 our authentication behavior was the following:
- executing command using svn.exe, for instance "svn udpate"
- getting "authentication realm" from process output
- destroying process
- creating correct credential cache for the obtained "authentication
realm" (for instance, correct file with encrypted password in the "auth"
folder for Windows)
- executing command using svn.exe once again - so that authentication
goes smoothly as necessary information is in credential cache
With Subversion 1.8 client we can not get "authentication realm" to
create correct credential cache information:
- if not specifying "--force-interactive" flag or specifying
"--non-interactive" flag - process output contains authentication
failure message, but only with repository url - not the "authentication
realm"
- if specifying "--force-interactive" flag - process "hangs" not
providing any output - so there is no way to get "authentication realm"
from it and then destroy the process
So the question is - is it possible to somehow return previous behavior
of svn.exe client - so that it does not "hang" but just "waiting" for
the "user input" providing necessary "authentication realm" in the output?
Or what would you recommend in such situation when authentication is
necessary when interacting with svn.exe utility from java application?
Is directly specifying "--username" and "--password" keys the only
available option?
Many thanks,
Konstantin
--
Konstantin Kolosovsky
Software Developer
JetBrains
http://www.jetbrains.com
"Develop with pleasure!"
Re: Subversion 1.8 "--non-interactive" and "--force-interactive"
flags behavior
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 5, 2013 at 10:20 AM, Branko Čibej <br...@wandisco.com> wrote:
>>> The better option of course is to just use the JavaHL API instead.
>> I have seen this problem as well. We have a Java server application
>> that scripts the command line so that it can retrieve and accept the
>> SSL certificate. We added the new --force-interactive option but the
>> problem is that the prompting seems to happen in the process that
>> started the Java server application instead of in the application
>> itself. So it is no longer possible to capture the command line output
>> with the certificate details and accept it.
>
> It has nothing to do with processes. We prompt the terminal, and read
> responses from the terminal, instead of using stderr for the prompt and
> stdin for the response. Note that on Windows, this was always the case
> for certain kinds of prompts. 1.8 merely makes that consistent.
>
>> Personally, I think this is a regression and not an improvement.
>
> You had a year and a half to raise this on dev@. :)
When the changes were made I just assumed Java apps would still work.
I assumed the code would just see the JVM as being the terminal. I
also generally trust the dev team to not introduce regressions. Guess
I was wrong on both counts.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.8 "--non-interactive" and "--force-interactive"
flags behavior
Posted by Branko Čibej <br...@wandisco.com>.
On 05.08.2013 16:12, Mark Phippard wrote:
> On Mon, Aug 5, 2013 at 10:03 AM, Branko Čibej <br...@wandisco.com> wrote:
>> On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
>>> Hi Everyone,
>>>
>>> I've got a question about "--non-interactive" and
>>> "--force-interactive" flags behavior in Subversion 1.8.
>>> I'm not subscribed to the mailing list, please put my email in Cc in
>>> any responses.
>>>
>>> We've got java application interacting with svn.exe command line
>>> utility. For Subversion 1.7 our authentication behavior was the following:
>>> - executing command using svn.exe, for instance "svn udpate"
>>> - getting "authentication realm" from process output
>>> - destroying process
>>> - creating correct credential cache for the obtained "authentication
>>> realm" (for instance, correct file with encrypted password in the
>>> "auth" folder for Windows)
>>> - executing command using svn.exe once again - so that authentication
>>> goes smoothly as necessary information is in credential cache
>>>
>>> With Subversion 1.8 client we can not get "authentication realm" to
>>> create correct credential cache information:
>>> - if not specifying "--force-interactive" flag or specifying
>>> "--non-interactive" flag - process output contains authentication
>>> failure message, but only with repository url - not the
>>> "authentication realm"
>>> - if specifying "--force-interactive" flag - process "hangs" not
>>> providing any output - so there is no way to get "authentication
>>> realm" from it and then destroy the process
>>>
>>> So the question is - is it possible to somehow return previous
>>> behavior of svn.exe client - so that it does not "hang" but just
>>> "waiting" for the "user input" providing necessary "authentication
>>> realm" in the output?
>>> Or what would you recommend in such situation when authentication is
>>> necessary when interacting with svn.exe utility from java application?
>>> Is directly specifying "--username" and "--password" keys the only
>>> available option?
>> If you use --force-interactive, you're telling Subversion to prompt the
>> terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
>> last resort. So for scripting the command-line client the way you're
>> doing, I'd recommend to pass --non-interactive and --username and
>> --password.
>>
>> The better option of course is to just use the JavaHL API instead.
> I have seen this problem as well. We have a Java server application
> that scripts the command line so that it can retrieve and accept the
> SSL certificate. We added the new --force-interactive option but the
> problem is that the prompting seems to happen in the process that
> started the Java server application instead of in the application
> itself. So it is no longer possible to capture the command line output
> with the certificate details and accept it.
It has nothing to do with processes. We prompt the terminal, and read
responses from the terminal, instead of using stderr for the prompt and
stdin for the response. Note that on Windows, this was always the case
for certain kinds of prompts. 1.8 merely makes that consistent.
> Personally, I think this is a regression and not an improvement.
You had a year and a half to raise this on dev@. :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: Subversion 1.8 "--non-interactive" and "--force-interactive"
flags behavior
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 5, 2013 at 10:03 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
>> Hi Everyone,
>>
>> I've got a question about "--non-interactive" and
>> "--force-interactive" flags behavior in Subversion 1.8.
>> I'm not subscribed to the mailing list, please put my email in Cc in
>> any responses.
>>
>> We've got java application interacting with svn.exe command line
>> utility. For Subversion 1.7 our authentication behavior was the following:
>> - executing command using svn.exe, for instance "svn udpate"
>> - getting "authentication realm" from process output
>> - destroying process
>> - creating correct credential cache for the obtained "authentication
>> realm" (for instance, correct file with encrypted password in the
>> "auth" folder for Windows)
>> - executing command using svn.exe once again - so that authentication
>> goes smoothly as necessary information is in credential cache
>>
>> With Subversion 1.8 client we can not get "authentication realm" to
>> create correct credential cache information:
>> - if not specifying "--force-interactive" flag or specifying
>> "--non-interactive" flag - process output contains authentication
>> failure message, but only with repository url - not the
>> "authentication realm"
>> - if specifying "--force-interactive" flag - process "hangs" not
>> providing any output - so there is no way to get "authentication
>> realm" from it and then destroy the process
>>
>> So the question is - is it possible to somehow return previous
>> behavior of svn.exe client - so that it does not "hang" but just
>> "waiting" for the "user input" providing necessary "authentication
>> realm" in the output?
>> Or what would you recommend in such situation when authentication is
>> necessary when interacting with svn.exe utility from java application?
>> Is directly specifying "--username" and "--password" keys the only
>> available option?
>
> If you use --force-interactive, you're telling Subversion to prompt the
> terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
> last resort. So for scripting the command-line client the way you're
> doing, I'd recommend to pass --non-interactive and --username and
> --password.
>
> The better option of course is to just use the JavaHL API instead.
I have seen this problem as well. We have a Java server application
that scripts the command line so that it can retrieve and accept the
SSL certificate. We added the new --force-interactive option but the
problem is that the prompting seems to happen in the process that
started the Java server application instead of in the application
itself. So it is no longer possible to capture the command line output
with the certificate details and accept it.
Personally, I think this is a regression and not an improvement.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.8 "--non-interactive" and "--force-interactive"
flags behavior
Posted by Branko Čibej <br...@wandisco.com>.
On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
> Hi Everyone,
>
> I've got a question about "--non-interactive" and
> "--force-interactive" flags behavior in Subversion 1.8.
> I'm not subscribed to the mailing list, please put my email in Cc in
> any responses.
>
> We've got java application interacting with svn.exe command line
> utility. For Subversion 1.7 our authentication behavior was the following:
> - executing command using svn.exe, for instance "svn udpate"
> - getting "authentication realm" from process output
> - destroying process
> - creating correct credential cache for the obtained "authentication
> realm" (for instance, correct file with encrypted password in the
> "auth" folder for Windows)
> - executing command using svn.exe once again - so that authentication
> goes smoothly as necessary information is in credential cache
>
> With Subversion 1.8 client we can not get "authentication realm" to
> create correct credential cache information:
> - if not specifying "--force-interactive" flag or specifying
> "--non-interactive" flag - process output contains authentication
> failure message, but only with repository url - not the
> "authentication realm"
> - if specifying "--force-interactive" flag - process "hangs" not
> providing any output - so there is no way to get "authentication
> realm" from it and then destroy the process
>
> So the question is - is it possible to somehow return previous
> behavior of svn.exe client - so that it does not "hang" but just
> "waiting" for the "user input" providing necessary "authentication
> realm" in the output?
> Or what would you recommend in such situation when authentication is
> necessary when interacting with svn.exe utility from java application?
> Is directly specifying "--username" and "--password" keys the only
> available option?
If you use --force-interactive, you're telling Subversion to prompt the
terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
last resort. So for scripting the command-line client the way you're
doing, I'd recommend to pass --non-interactive and --username and
--password.
The better option of course is to just use the JavaHL API instead.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com