Hi i am trying to use TMS software to download a file. But cannot seem to get the file to download.
i use the following code, and have written in an exception handler which keeps telling me that the URL cannot be found. Any help would be appreciated.
main.WebCopy1.Items.Clear;
with main.WebCopy1.Items.Add do
begin
FTPHost :=fHost;
FTPUserID := fusername;
FTPPassword := fPass;
URL := '\Setup\libmysql.dll';
Protocol := wpFTP;
CopyNewerOnly := true;
TargetDir := 'c:\Program Files\myfolder\';
end;
main.WebCopy1.Execute;
May i just add, i just tested the same code and url in another project that i had written and it worked.
Thank You
Things I would try:
use the debugger and check the code which connects and sends the HTTP request
check your HTTP server log file to see which resource has been requested
use a HTTP proxy (Fiddler) to intercept and analyze the HTTP traffic between the Delphi application and your HTTP server
extract the relevant part of the two projects, then diff their sources
(both with the working and the non-working application).
Sorry guys i found the problem. The connection was not set to passive.
I checked on the server and could not find that any connection was being made to the ftp account, and realized that the problem was not the path, it was the connection.
So i checked and saw the connection was set to passive, changed it an vualla, it worked.
So Now We know, For it to work passive must be set to true.
Thanks alot anyway guys
Related
I have a IIS and WebDAV under windows 10. Now I tried Delphi 10.4 Webdav component from /n Software which works fine for retrieving a particular file via WebDAV in SSL mode (https). But when I want to try to get the Directory listing I get an HTTP ERROR 403. In the log File on the server I see that the PROPFIND entry has the 403 Error note. It is similar that reason: IIS-403 err
HAs anyone here an idea where I could solve this problem.
Thanks a lot.
The reason is: (Answered by Hugh Wright from /n software)
There are several potential causes for this error. Previous users who have had similar errors fixed it by changing the depth property of the WebDAV component. By default, the WebDAV component uses a depth of infinity when calling certain methods, including FindProperties and ListDirectory. Some servers do not support requests with a depth of infinity, and may return a 403 error when the request is made.
Webdav1.User := 'username';
Webdav1.Password := 'password';
Webdav1.AuthScheme := authBasic;
Webdav1.Depth := dpImmediateChildren; // The server will operate on the
// collection resource URI and all of
// its immediate member resources (but
// on none of their member resources).
Webdav1.FindProperties('ResourceURI');
I was able to confirm that the issue was the Depth Property. By default, CarotDAV uses a depth of 1 (Immediate Children), and our component does not.
Can anyone diagnose my failure to connect to smtp.office365.com using Delphi 2010 and Indy 10.5.5?
I have read the code examples provided by Indy expert Remy Lebeau in this question: Using INDY 10 SMTP with Office365.
I have taken each of the two alternate code samples (one using AuthType satDefault and the other satSASL) from that question and cut-and-pasted them into a console application. In each case get the following error when run:
EIdOSSLUnderlyingCryptoError: Error connecting with SSL.
Error connecting with SSL.
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
When I change UseTLS to utUseExplicitTLS (as suggested in some other answers that state a plain text connection is required before attempting TLS) I get the following error:
EIdOSSLConnectError: Error connecting with SSL.
Error connecting with SSL.
EOF was observed that violates the protocol
I notice some references in other answers to setting SSLOptions.SSLVersions instead of SSLOptions.Method (which is said to be deprecated) but that property does not appear to exist on TIdSSLIOHandlerSocketOpenSSL in my version of Indy.
I believe I have the version of Indy which shipped with the D2010 updates but that it's somewhat out-of-date. I would be willing to update a newer version if one exists but can't seem to find anyway to do so without installing SVN, learning it, checking out from Development, and recompiling.
Finally, I've tried running all four variants of my console application with no DLLs present in the executable directory and with the DLLs from OpenSSL v1.0.2h present without any apparent effect.
EDIT: One other piece of information. The SMTP credentials supplied by the client (this project sends emails through a single dedicated outbound email address) is of the form project#myclientsdomain.com, rather than #office365.
Apparently, since Remy wrote the answer in the linked question, Office365 has stopped supporting SSLv3 (presumably to avoid a known exploit) and now requires TLS. The code from his answer in the original question works if you change these two lines:
idSMTP1.UseTLS := utUseImplicitTLS;
TIdSSLIOHandlerSocketOpenSSL(idSMTP1.IOHandler).SSLOptions.Method := sslvSSLv3;
to:
idSMTP1.UseTLS := utUseExplicitTLS;
TIdSSLIOHandlerSocketOpenSSL(idSMTP1.IOHandler).SSLOptions.Method := sslvTLSv1;
I am trying to create a sample Delphi XE7 desktop app that will connect to SSRS 2005 web service but every time I try to call LoadReport web method, the following error is shown:
This is what I have done so far:
Create a desktop app.
Import WSDL for ReportExecution2005 and ReportService2005.
Create a button that call the web service based on the code shown
here. The web service locations as well as report are hardcoded for
simplicity purposes.
This is the code snippet from the link:
HTExec := tHttpRio.Create(nil);
rsExec := GetReportExecutionServiceSoap(False, ExecURL, HTExec);
// Load the selected report.
LRParams.Report := 'ReportName';
LoadParamsResponse := rsExec.LoadReport(LRParams); //here it fails
Note: I have already created a .NET win form app (VS2010 and VS2013) that consumes this web service without any issues, thus I know the web service and report to render are working OK. Sadly our requirements is for a Delphi solution, My educated guess is that the WSDL importer generated code is not correct and somebody out there may have come across with this issue before and know how to solve it.
I did a quick search for "http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/LoadReport"
and found this.
If it applies to you as well, it may be the case you're calling the service on an incorrect URL, use the one with ReportExecution2005.asmxin it, not ReportService2005.asmx
(There's a lot more here)
To find out differences between the Delphi version and the working version, use a HTTP proxy (Fiddler2) to capture the SOAP HTTP traffic in both setups.
If you have no access to the working environment, use SoapUI to create SOAP requests.
I'm using the TIdSSLIOHandlerSocketOpenSSL Indy component in Delphi XE2 to send data to an SSL server (Apple Push Notification Service) over TCP. I've got it working to a degree but not sure if I'm going about it the best way. I'm doing the following :
Set the SSL properties inc. path to certificates
Call the .Open method to open the connection
Check the AType parameter in the OnStatusInfoEx event until I get a 'Handshake Done'
Send the data using .WriteDirect
Close the connection with .Close
Is there a better way to know when the connection is ready to send data? Does anybody have sample code using the TIdSSLIOHandlerSocketOpenSSL component directly over TCP? The samples I've found are mainly for HTTP calls where the TIdSSLIOHandlerSocketOpenSSL component is just attached to secure the connection.
Since you are using the client component, you only need to setup the certificates on the client if the server is going to authenticate the client's certificate.
Otherwise, set the TIdSSLIOHandlerSocketOpenSSL's SSLOptions.Mode to sslmClient, and you should be able to connect.
It's a good idea to enable the VerifyMode and use the OnVerifyPeer event on the socket component to verify the fingerprint on the server certificate in order to avoid man in the middle attacks.
Depending on your version of Indy, you may need to set the SSLOptions Method to sslvTLSv1. Some web servers no longer support SSLv2, which Indy 9 defaults to.
Here's some sample code that demonstrates retrieving a web page over SSL using the TCP component:
procedure TForm1.Button1Click(Sender: TObject);
var
s: String;
begin
IdTCPClient1.Host := 'example.com';
IdTCPClient1.Port := 443;
IdTCPClient1.Connect;
IdTCPClient1.WriteLn('GET / HTTP/1.1');
IdTCPClient1.WriteLn('Host: example.com');
IdTCPClient1.WriteLn('');
// Retrieve all the data until the server closes the connection
s := IdTCPClient1.AllData;
Memo1.Lines.Add(s);
end;
Don't forget to include the OpenSSL libraries libeay32.sll and ssleay32.dll in the same folder as your EXE on Windows. Use the standard (latest) binaries for Indy 10.
This is what works for me. I am using Delphi 2010, but it this probably works just as well on Delphi XE2 (not tested). I use the current tip revision of Indy, which is revision 4774, rather that the out-of-the-box version.
I have 3 components on a datamodule or webmodule:
TIdHTTP
TIdSSLIOHandlerSocketOpenSSL
TidCookieManager
Hook all the components up to each other at design-time, with the following change at run-time: If the protocol is plain http:, then disconnect the TIdSSLIOHandlerSocketOpenSSL component. If the protocol is https:, then set the Handler property of the IdHTTP to the IdSSLIOHandlerSocketOpenSSL.
In the SSL Options, set method to sslvSSLv23 and SSLVersions to [sslvSSLv2,sslvSSLv3,sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2]. I found that other permutations these properties just did not work. I can't explain it. I just know that this works with a wide range of webservers.
From there it is dead easy. To GET, simple call the Get() method on the TIdHTTP. For POST, call Post(). Parameters and Cookies are accessible by obviously named properties.
I had a lot of trouble get the out-of-the-box version to POST correctly, but with the tip revision, and setting the options as I mentioned, its been a breeze.
I have some problems on files which are placed in a LAN: there is a single Delphi program (server) which should write some files, which can be only read by multiple Deplhi programs (clients).
I use these simple instructions in the server for writing (DataList is a TStrings):
Stream:=TFileStream.Create(filePath,fmOpenWrite or fmShareDenyWrite);
try
DataList.SaveToStream(Stream);
finally
Stream.Free;
end;
The clients check every 5 seconds if the file above is modified (by just checking the FileAge), and if modifications are occurred, they load the DataList in the following way:
try
Stream:=TFileStream.Create(filePath,fmOpenRead or fmShareDenyNone);
DataList.LoadFromStream(Stream);
finally
Stream.Free;
end;
Normally everything works perfectly, but sometimes it happens that the server or the client raise an exception because "the file is in use by other process".
I don't understand which is the problem: I tried many alternatives, but this can happen also with just the server and only one istance of the client running..
Any ideas?
Thanks!
By design, network file systems can't be trusted. At least, NFS (in Linux) and SMB (in Windows) have no proven lock feature: concurrent access is not safe.
You need to use a Client-Server protocol to ensure that shared data is safe. You can use TCP/IP, HTTP or any other mean.
I recommend using a true service implementation, like DataSnap, RemObjects or our Open Source mORMot.