Leaderboard

Please go fight in private and stop killing this great thread.

Yepp, I know why 😄 The original Welcome Page was designed by me during the field test, and at that time "wuppdi" was the "thing" at the German Delphi Praxis, and I wanted to include that somehow and that's how it ended up there 😄 wuppdi is a simple CSS class to hide different things. doShow CSS class was used to override wuppdi 😄

Oh - there must be a wrong default-value. I will check this later today. Thanks for reporting - and of course thank you for using this welcome-page. 🙂 //Edit: Yes, there was a minor glitch in the code. If the config-file mentioned by Uwe does not exist, the default value for the width is 0px - which might be a little narrow for one or the other... New version is 1.2.9 fixing exactly this problem. If it does not occur on your system, you're perfectly equipped with version 1.2.8.

If the term pebcak is offending you must be new to the internet. I simply explained the way that always works for installing jcl/jvcl 1. The same as always - jcl\lib\d27\win32 or win64 and jcl\source\include 2. Yes, works JCL/JVCL setup issues are almost always a problem with not properly executing them or rather not having the latest jcl/jvcl sources or having some old stuff lying around. Maybe you did not update the submodule and are missing on the defines for 10.4 Also did you select both (10.4 32bit and 10.4 64bit)? And did not set the "Install selected only" checkbox?

Clearly a pebcak. Just pulled the jcl repo, ran install.bat - it compiled the setup using 10.4 and then I installed JCL for 10.4 32bit and 64bit without a problem

In your scheme with tokens FTP is useless IMHO. Do everything with HTTP. You'd have to use custom clients anyway (to utilize token stuff) so no sense in FTP at all. Alternatively, you can really deal with temporary logins and folders personal for each user. This way FTP is fine and any standard client could be used. Expiration could be done by the moment of last activity

Until Delphi 10.3, Search Declaration (e.g. CTRL-click on an identifier) in many cases did not work at all. Now it seems to work flawlessly. - Good work, Embarcadero!

... that was not my point. i think dmitry can handle something. ...some infos

If you are using HTTP for authentication, then why not just keep using HTTP for the file transfers, too? That is doable. However, there is nothing in the FTP protocol to handle such tokens, so that will have to be transmitted as the username/password/account for the session. But once authenticated, you can set the TIdFTPServerContext.HomeDir and TIdFTPServerContext.CurrentDir properties as needed. There is nothing in the FTP protocol to handle that. I would suggest simply deleting the token from the database as soon as a client logs in with it, making it a session token. That way, noone else can login with that same token, and it will be invalidated once the client disconnects. Yes, you can store custom data in the TIdFTPServerContext on a per-client basis. You definately do not want to query the database on every transfer. That will not work. There is nothing in the FTP protocol that would allow for such data on a per-request basis. But, the client can login with the token, and the server can validate it at the time of login and remember that the client is allowed to upload, and then the client can freely upload files as needed. Not necessary if the token is deleted as soon as it is redeemed during login. However, if would be trivial to remember the expire time on a per-client basis, and the server could validate the expiration on each file transfer, if needed. Same restrictions apply as above. Well, then now you are back to hitting the database on each file transfer, which is not a good thing for performance. You don't need to use CommandHandlers for this. TIdFTPServer does that internally for you. TIdFTPServer has OnUserLogin, OnUserAccount, OnStoreFile, and OnRetrieveFile events that you can use instead. Yes, a windows service would be a good idea. That is a very broad question with many possible different solutions.

Yes. You cannot bind to an IP that does not belong to the local device that your server is running on. Alternatively, you can bind to '0.0.0.0' to listen on all local IPv4 addresses with a single socket (use '::0' for IPv6). The TIdFTP.ExternalIP property is for use with active-mode file transfers when the FTP session passes through a proxy/router. In active mode, an FTP client has to open a listening socket to receive an inbound TCP connection from the FTP server. As such, it needs to tell the FTP server which IP to connect to, which can't be the local IP when the client is running behind a proxy/router. The TIdFTP.ServerHOST property is used with virtual FTP server hosting, it has nothing to do with file transfers. An FTP server can host multiple sites on the same server IP. So, to differentiate which site an FTP client wants to access, it must send a HOST command to the FTP server. When the TIdFTP.UseHOST property is True, TIdFTP sends the HOST command before performing user authentication. If the TIdFTP.ServerHOST property is blank, the TIdFTP.Host property is used. TIdFTPServer has an OnHostCheck event, and a TIdFTPServerContext.Host property, for handling HOST commands from clients. Only the TIdFTP.ExternalIP property deals with file transfers. The TIdFTP.ServerHOST property has nothing to do with that. The TIdFTP.DataPort property is the local port that TIdFTP will listen on, and the FTP server will connect to, for active-mode transfers. If it is 0 (the default), an available random ephemeral port will be chosen by the OS. If TIdFTP is running behind a proxy/router, you need to set the TIdFTP.ExternalIP property to the proxy/router's public IP, and enable Port Forwarding on your proxy/router to forward inbound traffic from the router's public IP/DataPort to TIdFTP's listening Binding.IP/DataPort. If TIdFTPServer is running behind a proxy/router, you don't need to set the TIdFTP.ExternalIP (unless TIdFTP is also behind a proxy/router), but you do need to enable Port Forwarding on your server's proxy/router to forward inbound traffic from the router's public IP/Port to TIdFTPServer's listening Binding.IP/Port (not DataPort), as well as port forwarding for any ports you setup in TIdFTPServer's DefaultDataPort or PASVBoundPort(Min|Max) properties. The TIdFTP.Host property is the hostname/IP that TIdFTP will connect to when you call TIdFTP.Connect(), so it can't be blank. Having TIdFTP connect to the proxy/router's public IP will not work, since there is no FTP server running at that IP. That is merely the proxy/router's public IP to the outside world. The TIdFTP.ServerHOST property has no effect on where TIdFTP.Connect() connects to.

Thanks a lot ! The proposed here changes will be in 10.4 Update 1 with some modifications. Mostly due to new cross-platform AtomicCmpExchange128 for 64bit platforms.

I answered your question on the Spring4D forum - sometimes I have weekend or vacation - thus no immediate answer 😉

Will this server be open to the public? If so, please consider a finished, polished and most importantly relatively safe commercial/OS product. Though your token solution sounds good, it may not be once you have implemented it. Exposing yourself or maybe worse your customers like this should be given a lot of thought - and know how. First off, you should use FTPS or SFTP, not plain old FTP. If I had to, and I mean really head to, I would use FileZilla and for each user their own folders, without possibility to get out of that (resulting most likely in a Linux file system). Then into every folder a sym link (or whatever the're called) to the files they may retrieve.

I have updated the demo. The demo now includes saving and loading refresh tokens, as well as checking for expired access_tokens and refreshing them with the refresh_token. Have a look at https://github.com/geoffsmith82/GmailAuthSMTP/ Geoffrey

There are probably still a couple of bug fixes and lots of performance improvements to be done. Until then new features are lower priority.

No problem: HKEY_CURRENT_USER\Software\Raabe Software\MMX\14.0