Indy 10 has been working great on my old D7. When loading the demos the changes in Indy 10 are updating the demo app. The only demo I am having an issue with is the Chat 2 demo. The idTCPServer and idTCPClient have changed dramatically since Indy 9. Would it be possible for one you delphi pros to take a look at it and update it. It's been a long time since I worked with delphi (I feel like I've been in hibernation for 10 years) . I wish I could update my delphi but D7 will have to work for now.
LOL - I didn't think I would get a response like that.. You are the developer and can dictate what ever your app does and does not . We are currently using all kinds of apps that are connecting to a server which records everything we type and even our current location. If you were able to wrote an app that would directly connect you to another user then a private chat would actually be private. (no outside server). Just thinking outside the box that we currently live in....
so it would have no way to encode it without complicated parsing.
dont remember.. if they are separated out, then yes it should escape htem.
this is interesting: c# doesn't do that..
var xUrl = new UriBuilder();
xUrl.Host = "localhost";
xUrl.UserName = "mterwoord@github.com";
xUrl.Password = "Pass:!@";
// xUrl.ToString() -> http://mterwoord@github.com:Pass:!@@localhost/
not trying to say that indy should match .net behavior per se, but worth investigating why that is...
(imo)
Though it seems that https://www.smartftp.com/support/kb/url-that-contains-in-password-f187.html does it that way.
Indeed: https://tools.ietf.org/html/rfc1738#section-3.1 indicates @ : / need escaping.
@rlebeau
@jpluimers: https://tools.ietf.org/html/rfc3986#section-3.2.1 allows only
userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) which excludes @
The official syntax for URLs, which other formats are a subset of, is RFC 3986. Note that TIdURI is very old and doesn't follow very many parsing/encoding rules at all and was never RFC compliant. There are a lot of things it doesn't handle right. I have a replacement in works (TIdIRI) that implements RFC 3987, with descendants for scheme-specific RFCs, and will obsolute TIdURI.
Hi. Hope someone might be able to help me out here. Having a bit of an issue with connecting to an API of our webstore platform (ECWID). For legacy reasons, I am afraid I am still using INDY9 on D2007 (it's a grid component that is not available passed D2007 that holds us back a little). Anyway, we use HTTP/SSL to connect and process through the API. On Oct 11th this stopped working for no reason our end. Nothing changed here for a few months with this software so I know it was not here. Eventually, ECWID developer support admitted the had disabled an unsafe cipher on Oct 11th, so that matched up. They renabled it and the software worked again. But they disabled it immediately as they say it is unsafe. But it breaks our software. I thought it might be just a case of updating the SSL libraries. But the latest ones won't seem to load with Indy 9. The latest I can get to load still will not connect. Is there anything I can do to get this working? Any suggestions? I know ideally, Indy 10 might be the answer but in this instance it is just not possible.
This message was deleted
My other thought was to create a processor utility in Seattle/Indy10 (which I have at work) or Berlin/Indy10 (which I have at home). But I can't get this to work either. A very simple program just to use HTTP/SSL and a simple GET. Using the lastest SSL libraries (from Fulgan) just keeps coming up with an error (see below). I don't really want to go down this route though, I would rather be able to get the original programme working with calls within rather than have to call an external 'processor'.
Indy 9 version I am using which won't connect to the shop is 9.0.50 and Seattle version which erros as above is 10.6.2.5298
So they have told me, this is the cipher list: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
TLS1 and above
Thanks.
I suspect this might be an SSL issue. I have tried creating a Synapse version of the call and on an older SSL it failed. Using the lastest, it worked. So guess the dilemma looks like not being able to use a later version of SSL that is compatible with the API ciphers in Indy 9. It may be I have to abandon Indy for this project and revert to Synapse if there is not an easy fix, which I suspect it isn't.
Indy 9 uses customized versions of the OpenSSL DLLs and thus cannot utilize newer OpenSSL versions. You need Indy 10 for that. Indy 9 does support TLS 1.0, though, so I would think turning off 1 cipher would not break as long as the other ciphers are available. If you use a packet sniffer like Wireshark, you can see the cipher list that your app's version of OpenSSL is offering to the server during the handshake.
Another option would be to move your TCP logic to a DLL and update your app to use that, and then write the DLL using Indy 10. Along those same lines, you might consider moving your business logic out of your app to a separate DLL/process so it can be written in a modern Delphi version, and just leave the UI by itself written in D2007.
@rlebeau Thanks Remy. I have seen Wireshark mentioned many times on forums and help sites. I will install that and see what kind of data I get back. If I know which cipher fails from that, does that then help? Do I include a list of 'good' ciphers in the cipher list? The library idea seem like a good plan and the way forward. I need to get this working asap in the short term, so need to look at some quick fix options which might mean using Synapse in the the interim (which in tests seems to work, but not as easy as Indy to implement). Once it is working again, I can visit the library idea.
On the subject of Indy 10, I have tried it in Seatlle and get the error I mentioned right at the start. Any idea what that could be? "Ordinal 4430 could not be found...."