Moderator: Project members
SSL is an insecure legacy technology. It has been completely replaced by TLS over two decades ago.Support for SSL
What's the point?Supports SIZE command with dir LIST disabled
What the old server called aliases is now called mount points.Supports aliases listing
An extended permission system is planned for a future version. Note that permissions won't be exactly as in the old server, the old server allowed many nonsensical combinations of permissions.I figured I could just try the newest version (1.1.0) to get everything I need but the newest version does not even allow the admin to even set permissions like before. You have one choice, read or write. Before I had a bunch of settings I could use, like the ones shown below...
Not to split hairs but SSL and TLS are really the same thing aren't they? I mean in the same sense that SSL version 1.0 is the same thing as SSL version 2.0 etc. TLS is just the newest versions. The only reason it was changed to TLS from SSL is to split from Netscape development. But my apologies, when I said SSL support I was talking about any type of encryption really. You have some old versions that do NOT support SSL/TLS/encryption and I was just making it a point to include this as one of the requirements we now have when looking for FTP server software.SSL is an insecure legacy technology. It has been completely replaced by TLS over two decades ago.
To be honest and blunt, the point is it used to be a feature and it was taken away in later versions of FileZilla. I would not think it would hurt or even affect your user base in any way by adding this back. With the exception of making a few that might depend on it (like me) happy. I don't think it would be much effort either. I would assume you have logic to deny the command if LIST is not enabled so simply removing that would solve the issue of it not working I would think.What's the point?
Yes sir and this seems to work great. Thanks!What the old server called aliases is now called mount points.
Great news, a few things about this comment. I beg you to please consider adding the same permissions like you did before. Nonsensical in your mind might not actually be nonsensical to everyone's use case (as shown above in my explanation). Wouldn't the best approach just be to give the users the power and let them be able to set crazy permissions that make no sense? Let us make the mistakes or more to the point give us the freedom to set it up the way we would like the server to run. Taking away features is never a good idea, adding features is where developers should focus. Honestly, with the old permissions system I could argue a use case for any permissions combo you could come up with.An extended permission system is planned for a future version. Note that permissions won't be exactly as in the old server, the old server allowed many nonsensical combinations of permissions.
Intention: Install the newest version (1.1.0) and use it in production.Scenario #1
Intention: Install the latest version (0.9.60.2) of the beta branch and use it in production.Scenario #2
Intention: Install the last version (0.9.13b) of the beta branch that supported (ssl/tls, SIZE command with no LIST, and supports aliases) and use it in production.Scenario #3
Why not give each vendor its own user account and separate directory so that you can show after-the-fact which vendor a file came from?We have a single site/login used by multiple vendors. We have them set up to all share the same home directory. They send in work for us to process and we have a process that watches that one folder and moves the files where they need to go. For extra security and privacy we deny directory listing to that home directory and only allow write (for files) access so they can all upload the work to us. We only allow the following check mark "Write" on the old version with these access choices...
Because based on the contents of each file we know the vendor they come from. Each file is marked with a unique vendor id along with a bunch of other meta data. But it's not like I could not have set this up a different way in the past or went a different direction with my development of the application. It's that back when it was developed years and years ago, the environment was expected to be able to do a certain thing. Now the environment can no longer be updated (filezilla server) because it would not function the same way. As it stands having each vendor with it's own account would end up running into two brick walls...botg wrote: ↑2021-11-18 22:46Why not give each vendor its own user account and separate directory so that you can show after-the-fact which vendor a file came from?We have a single site/login used by multiple vendors. We have them set up to all share the same home directory. They send in work for us to process and we have a process that watches that one folder and moves the files where they need to go. For extra security and privacy we deny directory listing to that home directory and only allow write (for files) access so they can all upload the work to us. We only allow the following check mark "Write" on the old version with these access choices...
