Article Discussion: How to Create ASP Applications Without Writing ASP Code

How to Create ASP Applications Without Writing ASP Code If you have any questions or comments about this article please post them here.

You can read the article here .

Perhaps Robert should not be so arrogant in his author details when he clearly isn't good enough himself. Creating an object based upon query string parameters? Nice secure code.

Perhaps you should read the article to the end. Particularly the Security part.

---------
Security
Another common complaint is that the method exposes class names and that somehow it is dangerous. While I don't consider it a risk, if it makes you uncomfortable, simply mask the class names by changing them in the ASP file. In other words, if the class name is EmployeeDelete, have the URL pointing to exec.asp?cls=Employee&CMD=Delete. In the ASP file, you would have to catch this (using the QueryString collection) and do a Server.CreateObject on QueryString("cls") & QueryString("CMD").
---------

One wonders why that wasn't done in the first place then. You could argue it makes the code less easy to read, but people read code in articles and use it, regardless of its security implications because they know none the wiser.

Those haven't been in use for a while.
From Microsofts mouth


URL

The most common reason I've heard is the overhead associated with OnStartPage/OnEndPage. Plus the fact that those methods are deprecated means your app may not work on later versions of IIS.


I'm not going to touch on giving the users the ability to call methods of your VB classes, which may or may not be running under a priviliaged account on your server, from the querystring. Masking the class names is not enough. It's a bad idea. <---period.

If you want to make calls to server-side COM components directly from the querystring, ISAPI applications are a much better choice (check those buffer overruns though). I realize that programming an ISAPI application is no small matter. A Better choice would be to just break down and install the .NET runtime and develop them in ASP.NET.

uhmmmm, and if I may get a bit snarky for a second. Those young developers may be wrong, but I bet they aren't 4 years behind the times. Wake up and smell the 2000's man. Lets hope he isn't still using DAO when he's developing those various database applications.

URL

Hi, I am the author of the article and want to answer some of the criticisms.

About security. As I already explained in the article (Security section), it may not be the greatest of ideas to instantiate a COM object based on the QueryString. Normally, you are really dealing with only one project anyway, so it isn't really necessary to pass the project name anyway. Secondly, I already pointed out , you could mask the class names. Or you could have a class that has multiple commands. So you pass something like this: exec.asp?o=Employee&cmd=Update&...
Inside your COM object you map cmd=Update to the appropriate code path. The article is supposed to show the techniques and the mechanics, not security practices (though it addresses it). If you think about, just about ANY ASP site *IS* masking execution paths (i.e. Classes in this case). I've changed URLs several times on some sites to get them to do what I wanted (Staples rebate site, for instance), so this is NOT a problem just related to my method of writing web apps. You could do the same thing on the full ASP, PHP, JSP, ASP.NET or whatever site.

Security is not something you do by hiding your code (as breaking of proprietary encryption techniques has shown) - you do it by writing code well - that means using stored procs, systematic data and user validation, SQL cleanup, etc...

On to the next problem. skoon pointed out that OnStartPage/OnEndPage is deprecated. Thank you, I didn't know that. But keep in mind that the article was written in 1999, before the publication of the MSDN article which proclaimed the method obsolete. Even so, it will ALWAYS work. The Scripting object is provided by asp.dll, development for which has ceased. So for as long they distribute class ASP engine with IIS, the OnStartPage/OnEndPage method will continue to work. Applications I have written work right now on WinNT, Win2k and Win2k3 servers and it hasn't complained about the "obsoleteness" just yet. Regardless, thanks for the link - I will update the technique (or maybe I won't - I am switching to .net anyway) to use ObjectContext. Easy enough.

And last topic - skoon, I've been using ADO since 2.1.

Ever since I wrote the article, I've been getting emails from people who are religiosly and blindly attached to asp scripting. This method is very conducive to code generation and most applications I write nowadays are 50-60% generated. Chew on that one.

Regards,

Robert

I hate using COMs to create websites - debugging takes forever!

Instead of simply editing your ASP file then refreshing the page, when using COM's you need to:

Edit the Class in the project
Compile the project
Stop IIS
Unregister the old DLL (or can u just re-reg over the top of the old one)
Register the new DLL
Restart IIS

For me, the hassles outway the cleanliness. Having said that, on large projects where speed and code separation is desired/required, i will usually create a COM object.

Why do you need to compile the project. Just run your project inside the IDE, complete with breakpoints, debugging capabilities, etc...


>>I hate using COMs to create websites - debugging takes forever!

Instead of simply editing your ASP file then refreshing the page, when using COM's you need to:

Edit the Class in the project
Compile the project
Stop IIS
Unregister the old DLL (or can u just re-reg over the top of the old one)
Register the new DLL
Restart IIS

For me, the hassles outway the cleanliness. Having said that, on large projects where speed and code separation is desired/required, i will usually create a COM object.<<

Apologies for not knowing the article was written in 1999, the "published" date on the article posted here was Feb 25th 2003. Back in '99 I used the scriptingcontext object on a project I wrote too.

re: Debugging a COM object - If you use the MTS ObjectContext and register your DLL in an MTS/COM+ package, you don't have to stop the server, unregister, re-register, etc... as long as you haven't changed any of the method signatures. (e.g. inputs, outputs of the public functions) and you compile your project with binary compatibility.

One thing you could do is design an interface to base all of your ASP COM objects on. Then implement that interface in your specific ASP COM objects. Once you compile your object, all you have to work on is the private functions/subs. So no matter what you change, you don't have to dance the regsvr32 shuffle. The interface does require a little more work, since VB6 only supports "Editor Inheritance" unless you design a template class and have everybody use that. But it might make it easier for other people who have to work on your code when they are debugging it, they know what to expect from the object.