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.

[bigdave]

Ok, they have been relaxed and only "Most Risky" have been done.

[pablo]

Originally Posted by bigdave

Ok, they have been relaxed and only "Most Risky" have been done.

when are we going to be notified about features that will be disable?. Please notify us before doing the changes.

[pablo]

Let's see, aspupload is for uploading files, and that where we are using it for: saving files on the server, but also deleting them when necesary. I think those options are FUNDAMENTAL, and should not be disabled. I am not willing to do the deleting manually via ftp for all my customers (like techsupport suggested). Please let us know whether we will be able to use these options (if not in persits, are they available in dundas, and not risky?), otherwise we have to look for another provider.

Another issue is that it is not accpetable to change configuartions without notice, you guys should realize that many sites stopped working at the moment you implemented the change. Dont let the cure get worse that the pain. Please dont let this happen again and advise us well in advance!

[Silverbug]

You should be able to just delete the files using the FSO
http://www.w3schools.com/asp/met_deletefile.asp

[Brangwyn]

Originally Posted by Silverbug

You should be able to just delete the files using the FSO
http://www.w3schools.com/asp/met_deletefile.asp

I agree FSO should be used for manipulating files once Uploaded becuase its more fleixble and probably more efficient as well.

[Carly]

In reviewing the ASPUpload documentation provided in this thread and in response to tickets, ASPUpload is stating that UploadedFile.Delete is not affected by disabling the Delete File function. You should still be able to delete uploaded files using this function rather than DeleteFiles.asp. I don't believe Dave disabled OpenFile, so it shouldn't just be restricted to newly uploaded files.

While I agree that more notice should be given before making these changes, I think that disabling the "Most Risky Features" was done in the best interest of our clients and for the stability and security of our shared servers.