https://bz.apache.org/bugzilla/show_bug.cgi?id=58128
Bug ID: 58128
Summary: Can not use user name with at-sign in Ant SCP task.
Product: Ant
Version: 1.8.2
Hardware: Other
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Optional Tasks
Assignee: [email protected]
Reporter: [email protected]
Also see
http://stackoverflow.com/questions/12979503/how-to-escape-in-ant-scp-task which
describes a similar issue and solution. The problem has been checked also to be
in Scp.java revision 1342897.
The Ant SCP task allows copying files using sftp or scp protocol. The
parameters for the connection are intermixed with the file specifications, such
as:
...of the form user[:password]@host:/directory/path. ...
However, more and more companies are using logon codes such as
"[email protected]". The merits of that are to be discussed by historicians;
the presence is a fact of life.
With command line Unix sftp, these user names are recognized correctly:
$ sftp [email protected]@escrow.nl
Connecting to escrow.nl...
[email protected]@escrow.nl's password:
sftp>
However, the SCP task can not handle it:
BUILD FAILED
...build.xml:3383: com.jcraft.jsch.JSchException:
java.net.UnknownHostException: [email protected]
at com.jcraft.jsch.Util.createSocket(Util.java:258)
at com.jcraft.jsch.Session.connect(Session.java:186)
at com.jcraft.jsch.Session.connect(Session.java:145)
at
org.apache.tools.ant.taskdefs.optional.ssh.SSHBase.openSession(SSHBase.java:223)
at org.apache.tools.ant.taskdefs.optional.ssh.Scp.upload(Scp.java:299)
...
The parsing of the parameter such as:
<scp sftp="true" port="xxx" todir="[email protected]@escrow.nl:/test"
password="xxx" trust="true" >
leads to a host name [email protected], since the first at-sign is used as a
splitter.
Problems get even worse, because it is nowadays also not uncustomary that a
path contains an at-sign.
A solution with using `uri.lastIndexOf('@')` instead of `uri.indexOf('@')` will
probably not be a lasting problem, since filesystems and usernames are getting
more flexible. Although it is a bad habit to use @ or :, it might work on some
filesystems. The cause of the actual problem is that one parameter is used to
provide multiple values (in relational theory: not well normalized).
Workaround for this scenario is to abandon use of the scp task and use the
commandline variant instead which again introduces other possible problems.
Suggested correction is therefore to add two optional parameters: host
(optional), user (optional). Similar to the already existing parameter
'password' which is also available through the syntax for a filename, it allows
a user to specify a specific host and/or user. Whenever the parameter is
provided, the algorithm for chopping up the filename specification knows that
it does not have to expect a host and/or user in the filename specification, so
a possible @ or : must be part of the path.
--
You are receiving this mail because:
You are the assignee for the bug.
