Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 29 22:06
    alejandrolaorden commented #436
  • Jan 29 21:24
    rlebeau commented #436
  • Jan 29 17:25
    alejandrolaorden commented #436
  • Jan 28 01:58

    rlebeau on Indy11-preparation

    Updating TIdSocketList.Add() on… (compare)

  • Jan 27 18:00

    rlebeau on master

    #445 Updating TIdSocketList.Add… (compare)

  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau labeled #445
  • Jan 27 17:19
    rlebeau assigned #445
  • Jan 27 17:19
    rlebeau edited #445
  • Jan 27 13:50
    MaxRusov edited #445
  • Jan 27 13:28
    MaxRusov opened #445
  • Jan 17 17:13
    rlebeau commented #225
  • Jan 17 12:50
    tothpaul commented #225
  • Jan 14 02:25

    rlebeau on Indy11-preparation

    Bringing in some more updates f… (compare)

  • Jan 13 17:12
    hafedh-trimeche closed #444
  • Jan 13 16:57
    rlebeau commented #444
  • Jan 13 16:56
    rlebeau commented #444
  • Jan 13 16:55
    rlebeau commented #444
  • Jan 13 13:59
    hafedh-trimeche opened #444
Kudzu
@czhower
Well if it works.. no need to drop it.
Remy Lebeau
@rlebeau
For the most part, Indy works fine in the old versions
EricKing1
@EricKing1
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.
EricKing1
@EricKing1
This is amazing.... After 20 years the indy package still works great. Kudos Kudzu and all who are assisting. I am beginning to see the possibilities... Wow, a cell phone with a server who would guess this would ever happen....
Ludwig Behm
@lbehm
a cell phone with a server who would guess this would ever happen....
that sounds really scary....
Matthijs ter Woord
@mterwoord
the app needs permissoins for that, and i wouldn't give it those.....
EricKing1
@EricKing1
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....
Kudzu
@czhower
Thanks. Remy though is largely the one carrying the torch into phones etc... I believe its mostly his efforts that got us there.
Jeroen Wiert Pluimers
@jpluimers
Shouldn't TIdURI.GetFullURI escape : and @ in usernames/passwords ?
Matthijs ter Woord
@mterwoord
@jpluimers Hi! :)
Kudzu
@czhower
@ is legit in URLs becuase of auto login
so it would have no way to encode it without complicated parsing.
Matthijs ter Woord
@mterwoord
does TIdURI let you specify a .Username and a.Password string?
Kudzu
@czhower
same for : IIRC but would have to lok at spec
dont remember.. if they are separated out, then yes it should escape htem.
Matthijs ter Woord
@mterwoord
last time i looked at delphi was today (fighting ole container, and stupid dev mistakes), last time before, no clue.. :)
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)
Ludwig Behm
@lbehm
@czhower I think @jpluimers means @ in the username part of an uri - which should be escaped.
Jeroen Wiert Pluimers
@jpluimers
I tried finding RFC info on this but my Google foo isn't helping much. There are some SO posts indicating %-hex escape but they don't make references to standards.
Matthijs ter Woord
@mterwoord
you saw RFC 1738?
and maybe 2141 or 2396
Jeroen Wiert Pluimers
@jpluimers
Indeed: https://tools.ietf.org/html/rfc1738#section-3.1 indicates @ : / need escaping.
Kudzu
@czhower
yes tehy do
@rlebeau
Jeroen Wiert Pluimers
@jpluimers
Which means .net is doing it wrong (:
Ludwig Behm
@lbehm
@jpluimers: https://tools.ietf.org/html/rfc3986#section-3.2.1 allows only userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) which excludes @
Jeroen Wiert Pluimers
@jpluimers
@devimplode oh nice: conflicting info (:
Ludwig Behm
@lbehm
@jpluimers why?
Jeroen Wiert Pluimers
@jpluimers
@devimplode disregard, I was sleeping while reading. Not a good combination (:
Remy Lebeau
@rlebeau
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.
Jeroen Wiert Pluimers
@jpluimers
Great! Let me know when there is something testable.
marbles99
@marbles99
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'.
marbles99
@marbles99
blob
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
Ludwig Behm
@lbehm
Which ciphers and tls protocols does the API support?
marbles99
@marbles99
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.
marbles99
@marbles99
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.
Remy Lebeau
@rlebeau
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.
Walter Prins
@ByteJuggler
@marbles99 Late to this, but, just to ask re "I know ideally, Indy 10 might be the answer but in this instance it is just not possible." Why? (Eric King has successfully installed latest Indy 10 on Delphi 7 recently? Too many dependencies on Indy 9 types or something?)
marbles99
@marbles99

@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...."