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)
and maybe 2141 or 2396
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...."
@ByteJuggler I can't remembet the exact reason why we stuck with Indy 9 for the legacy stuff in D2007. I think it might have been that we have some software that communicates using TCP servers/clients. If my memory serves me correctly, I tried Indy 10 when I reinstalled D2007 on a new PC and it looked like it was going to take some work to convert some of the software to Indy 10. You know what it is like some times, it seemed a quicker option to install Indy 9 so the software would compile. But it is times like this and the problems I have now, that maybe that is false time economy. I probably still don't have the time to go down the Indy 10 on D2007 rout just yet. It would probably mean, for my own peace of mind, cloning my current disk so I have something workable to back to if I need to. Then I need to update and convert all the software. But my priority at the moment is to fix the broken web shop software that is not talking to the API as we are currently unable to automatically update prices and stock. But all these ideas I have taken on board and will return to once I have sorted this other issue. Thanks :)
@marbles99 Something to do with the particular version of OpenSSL libraries getting pulled in I think. I seem to vaguely recall having had a similar problem in the past and that it boiled down to finding a suitable of SSL libraries. (As I recall not all the Windows libraries are built equal, sorry if this is very vague, it's been a while.) I think (rummaging around my bookmarks) I might've used the build from here eventually: http://slproweb.com/products/Win32OpenSSL.html I would suggest trying a build from there (assuming I'm right and not leading you down the garden path). It should be enough to put libeay32.dll and ssleay32.dll alongside your service/application executable, but to be sure you're not accidentally loading the wrong version you may want to search the machine and rename and/or disable any other versions of these files before testing. (Use "Everything" from voidtools to quickly find all copies of any named file.)
@marbles99 For what it's worth, I seem to remember that, back in the day we were faced with the upgrade from Indy9 to Indy10 it turned out to be slightly less hassle than initially anticipated -- it initially seemed like a lot of work because the breakages seemed bigger than they turned out to be in the end. (Again it's been a while, and obviously YMMV, I have no idea how complicated your dependencies are...)
@ByteJuggler Thanks for the quick replies. And for the link to the builds for the SSL libraries. I will take a look at that later today and see if I can see what we need. I am not sure if it will fix the Indy 9 issue as I have used the various versions available from Fulgan which appear to be the 'Indy versions' and there seems to be a point in the library version history where they no longer work with Indy 9 (won't load) but even the latest version there that will load won't connect to out web platform since they removed the cipher. And definitely a good idea to rename all the library DLLs ;) We use them quite extensively for communicating with carrier APIs, Amazon, Web shop platform etc and I wouldn't want to break something that isn't currently broken (except the web platform). I may clone my hard drive this evening and that will give me something easy to go back to. Haven't heard of voidtools, I will take a look. Thanks for your help - appreciated.