This content has been marked as final. Show 7 replies
I am having a similar problem creating a connection to the FTP server.
User is a client sitting behind a network with ISA firewall.
Contribute 3 worked fine, and still works fine, and the same credentials and FTP settings were used for Contribute 4
All ports were opened both ways on the ISA server to the website (ISA filter all ports open to the remote site with an IP address entered)
All other FTP clients work, DOS command line, WSFTP, etc and I am able to send a file and receive a file.
In the Contribute connection wizard's step after entering the FTP credentials it connects to the site and it shows all the folders and files present in that site, and in the step after where it asks me to enter the Remote Path Information, there is the forward slash as there should be, and the Choose button shows the website contents, but after clicking Next it eventually returns error "Contribute cannot verify your connection information. / Please contact your administrator for assistance.
I have tried many different ways, opened up firewalls, stopped them, added Contribute to exceptions list, installed a demo version the server itself and every attempt failed at the last step.
Help in resolving this problem would be much appreciated, I've been trying to fix this for weeks.
Some suggestions/guesses guys
kruss1971 - As the IP address works, but the domain name doesn't, this is some sort of DNS problem, i.e. a domain name to IP address conversion issue. I don't know why, but the domain to IP conversion is working OK to show you the files of the website, but at the point of verifying that connection the domain to IP conversion is not working. So, there are two lookups:
1. Domain to IP - to show you the files of the website. Works, because is done from your local machine.
2. Domain to IP - to verify the connection. Doesn't work - I'm thinking that maybe this is somehow because the DNS lookup is occurring from another location, i.e. external to your local computer, that's the difference, and that's why it doesn't work.
Just a guess. See also:
I am wondering whether it's because virtual paths on the server are involved, and these aren't matching up.
Contribute has to drop a file when it verfies the connection and the address locations all have to match up and this is what isn't happening.
2) Again I am thinking virtual paths issue here.
Just guesses. Try opening an official support query too.
Also, in the /_mm/contribute.xml (or at least in the Contribute 1 example I'm looking at), there is a section:
<url_alias value=' http://www.yoursite.co.uk/' />
<url_alias value=' http://11.22.333.44/' />
where different aliases are stored, and I am wondering whether that might be important to your issue.
I do not see a file called contribute.xml on the workstation, so I am not able to check. I even tried doing a search for a file containing parts of the file you suggested.
I have also tried using IP addresses as suggested in some forums, also to no avail.
The link you provided to me "webserver_contribute04" does give hints that it's the kind of problem I am facing, but I'm not sure I have that much control over my ISP's server configurations. If I can access it using any other FTP program, why should we have to go any further? I don't like the suggestions that Contribute is playing "guessing" games to work out where the website is and take another test that always fails.
I will keep searching for a solution, meanwhile.
The hub (configuration) file is in the _mm folder on your server. In Contribute versions 1 and 2, the hub file is called contribute.xml. In Contribute 3.x and 4, the hub file is called cthub[randomstring].csi.
Some other thoughts for you:
- Does the FTP account you are using to establish the connection have full permissions, particularly write permissions, because when the connection is established, Contribute must write the hub file to the server for the first time, so maybe that could be your problem? If you can't see a hub file on your server, it might suggest that the initial write of this file to your server is failing and that could be your problem.
- If the hub file has been written to your server, I suggest you need to investigate further the type of FTP messages that are generated as acknowledgements back to your local Contribute, and maybe these are getting intercepted somehow by your firewall???
If Contribute 3 can connect okay, and it is only Contribute 4 that can't connect, then maybe yours isn't a virtual paths issue.
Ok, I found that file on the server, and the url_alias values look correct to me.
If the FTP server received that file in the first place, then it means I have permissions to write to the folder.
It is quite possible that a reply is being intercepted by the firewall, however I have both ways open between the ISA server and the FTP server, an exclusive packet filter to allow everything between my server and that ftp server.
I tried renaming that file and attempting the connection again, and it failed. Interestingly, Contribute 4 did not replace it with a new one. I'm not sure how this process is supposed to work, but I know that I do have permissions to that folder because I can copy files back and forth with CuteFTP.
I will see what else I can look at on the firewall, although I am pretty sure that if Contribute 3 has no problem, then it can't be a firewall issue, although I am aware that Adobe redesigned the FTP engine in the latest versions of Contribute and Dreamweaver.
I would suggest attempting to Connect to your server with Contribute 4 from another location, i.e. one that is not behind the firewall etc - a home machine is usually ideal. At least then you will know whether this is a problem with your server settings (unlikely) or a problem with trying to connect from behind that firewall, which is the most likely explanation.