NT Servers - ASPUpload

[bigdave]

It appears we have had ASPUpload configured incorrectly for use in a shared environment and from a security standpoint. Changes have been made clusterwide for the NT machines so if you receive an error like the one below, please do what the error suggests.

Persits.Upload.1 error '800a0028'
This feature has been disabled by system administrator. Use 
File.SaveAsVirtual instead.
/foo/bar.asp, line 127

[pentom]

Originally Posted by bigdave

It appears we have had ASPUpload configured incorrectly for use in a shared environment and from a security standpoint. Changes have been made clusterwide for the NT machines so if you receive an error like the one below, please do what the error suggests.

Persits.Upload.1 error '800a0028'
This feature has been disabled by system administrator. Use 
File.SaveAsVirtual instead.
/foo/bar.asp, line 127

I'm getting errors on the directory listing portion of the asp upload component. I can still upload just fine, but can't display the listings using the generic directorylisting.asp file from persits. All I get is a general 500 error with no details or suggestions. Any ideas?

[pablo]

YOU ARE PUTTING US OUT OF BUSINESS!!!
This is a VERY SERIOUS CHANGE for us!!!
Actually we have chosen matrixreseller, because of you supporting this component. WE have 8 sites using these features, all off our 8 sites are not working anymore. we need at least 3 weeks to change all our programms. MY FIRST COMPLAINT IS THAT YOU CANT JUST DO THIS WITHOUT TELLING US ANYTHING AND GIVE US TIME TO SOLVE THIS. There was no warning at all!!!
AND WHAT IS WORSE, there is another option that is not working anymore: there’s a specific command in aspupload that is used to delete files from a specific path (upload.deletefile path), and we’ve been using it in every of the 8 sites. Now there is NO option for DELETING FILES anymore.
TECHSupport tells us to use ftp, but our customers dont know how to use ftp (and we dont want them to be forced to learn this either).
PLEASE THINK ABOUT THE CONSEQUENCES FIRST, and provide us with a solution!
paul

[Brangwyn]

You may actually just be able to use the Dundas uploader instead, the syntax is alsmot identical (becuase all these coms are based on a similar Class that someone first wrote anyway).

I'd agree though some advance notice would have been good, I had a customer several days before this was posted tell me his upload stopped working (we just changed to the dundas upload and his code basically still worked with .Save still), so I can only assume this notice was posted retrospectively?

[bigdave]

http://www.aspupload.com/manual_share.html

That is what I went by, these from my understanding this needed to be done. I am sorry for those I have effected. Paul, send me a PM and lets see what we can work out in the mean time.

[Brangwyn]

Thing is, almost everything you've disabled with that particular com object can be done other ways anyway either with other 3rd party COM's or MS Standard ones, and if you start trying to lock other things down then your going to get a whole heap of grief from users.

Personally if your going to do anything with that particular COM I would only lock down those they've listed under "Most Risky Features"

[DigitalSkyline]

I fully agree with brangwyn ... I don't use the component but I might want to someday!

Was there something that prompted this? If people aren't being responsible with it then you should get rid of the bad apples, but don't punish rest of us!

[bigdave]

I am open to suggestions on this one, now that I look I might have gone a little crazy in securing this com. What does everyone want/need?

[Brangwyn]

Everything they have listed there under "Most Risky" I'd agree with and should be locked down especially the ActiveX one.

As for the others, I'd just reenable .Save and see how we get on, I'd say thats probably what most people are using (most of their code examples use it) and probably most of the complaints todate are about that particular method no longer working.