I will be adding new pages and adding functionality to current pages.
I would basically like to use new technology and but I don't know how should I add it to classic ASP pages
In other words, can I <#--include--> an aspx page in Classic asp page? Or anything of that sort, may be creating a user control in ASP.NET and using it in classic ASP?
You shouldn't really add it to the existing classic ASP pages. You may want to perform a full (yet slow) migration from classic ASP to .Net. Otherwise, you may just simply want to add your new functionality in new pages completely. If you have a templated site, this may become a litle cumbersome because you will need to recreate those templates in .Net since mixing .Net and classic in the same file is not possible.
You could ultimately end up resorting to iframes, but this makes browsers goofy sometimes. If your application is dependent on session, you'll need to account for that because .Net can't access a classic session unless you stick to primitives (string/int/etc) and use an outside state provider (like SQL) to hold the data with a sessionid that can be passed.
Having a hybrid site is a very tricky prospect and not one to be taken lightly. Tread carefully or you'll really put yourself in a pickle.
EDIT: Partial Hybrid example description
We had a 700 or so page site to transfer from classic asp to Asp.Net 2.0. Many of the pages were allotted time to be completely transferred during a single project, but a few areas were unable to be refactored and had to be accommodated. We put together a master page architecture for the new .Net structure, data library and business objects library, and we began the transfer. In incorporating the classic asp pages, we determined we had a few needs.
Since master pages would control basic layout, menu, header, footer, we would need to remove these elements from any pages brought over.
New session requirements were incompatible with existing session capabilities.
Classic asp pages must still be required to obey .Net formsauthentication.
I solved these problems with the following solutions:
Our application is targeted at a specific customer, so we were able to determine browser requirements. This allowed us to employ an iframe to hold classic asp content/applications without worrying that the iframe would go crazy on us in Webkit or Firefox or whatever.
To accommodate the session requirements, we built a small encryption/decryption engine in .Net and in classic asp that enabled us to encrypt a "query string" to pass the session information back and forth. It wasn't super secure, just enough that the casual user would not be tempted to mess with data. In addition we had to build two translation files. The first translation file was a .Net library static method that would take the session data, extract the necessary pieces and create the query string. The second one was the classic asp version that was designed to read the query string, parse the data and create the session primitives directly.
Making the classic asp pages behave for .Net was a server management issue. To do this, using the formsauthentication attribute protection="All" is supposed to be sufficient, but I found it still did not cover items that had other handlers anticipated. So I added a wildcard mapping in IIS to handle all files. From the properties of the IIS website, choose "Home Directory" and click "Configuration". At the bottom of the next window is a "Wildcard application maps" box. Click insert and navigate to the version of .Net you use to find the aspnet_isapi.dll file. This will force all files to parse against this file (which is harmless except that it kicks up the authentication request).
I can't provide specific code samples because of NDA, but this should at least provide some ideas on where to go from here.
You can have classic ASP pages running inside an ASP.NET application. You can add your pages in ASP.NET
Related
I've got a lot of Classic ASP pages in production on a Windows Server 2003 64-bit machine. I've also got .NET on there working.
I'm starting to move the ASP ajax pages (pages that receive ajax calls from the Classic ASP) to ASP.NET/C# to take advantage of the business/data/logging layer I've got set up there in C#.
I've figured on securing the ASPX pages by way of a "token" that I create in the database in ASP and then pass to the ASPX page, which then uses it to validate that it's a legit call and destroys it.
My big question is - aside from making the ASPX pages, do I need to compile the app into the same site as the ASP site? I assumed I'd do that - deploy it there alongside the ASP Classic pages, and then just call the ASPX individually as needed.
Is this strategy sound? Do I need to do anything special for performance or configuration to make ASP Classic and ASP.NET coexist well?
Thanks - this migration has been a bear because of the extreme asp classic dependency.
It will work just fine. I've seen it on several sites. Just put them all in the same directory.
Your biggest issue will be that the ASP and ASP.NET pages will each have their own SESSION and APPLICATION variables which won't be shared between the two. If you are using session variables in either it can force you into doing a lot of hacks to make it all work together well.
I've read several places that ASP.NET are more secure than ASP Classic. But never seen any actual arguments of why.
Using a standard login system as an example.
The user sends a username and a password to the server via forms. This is done the same way in both languages. And in both languages the rest is done on the server.
Why choose ASP.NET over ASP Classic here?
As mentioned by ScottRFrost, Request Validation protects against XSS as default. Personally, I'd prefer to turn this off and develop an application to use output sanitisation insead (e.g. HTML encode output to web pages, or properly encode and escape output used in JavaScript). This approach doesn't restrict user input so it does not restrict application functionality in the way Request Validation does. e.g. It will allow HTML to be entered into a field which will be displayed on a webpage instead of interpreted by a browser (imagine a HTML developers forum that didn't allow HTML to be posted). If you use this method in ASP.NET, you would use a very similar approach to standard ASP development in terms of variable output to the page.
To answer your point, during authentication (validating a username/password combination) there is not much difference between Classic ASP and ASP.NET. ASP.NET provides some user controls that can be dropped into a page, and also provides the Membership Provider model, but essentially you have to implement the logic for this either way.
ASP.NET also has authoriazation compenents included as standard, so it is possible to restrict access to your whole application or certain URL paths from settings in the web.config fille. This guards against a developer forgetting to include authorisation checks on a per page basis. Any finer grained access checks will still need to be manually handled in ASP.NET though.
ASP.NET also provides specialised folders such as /App_Data that cannot be read via the web server. This gives a convenient place to store application related files that should not be read directly via HTTP. You can do this manually in Classic ASP, but you would need to either store this directory outside of the web root or you would need to set local folder permissions so that these files cannot be read by the IIS user.
To summarise, I would not say ASP.NET is inherently more secure than Classic ASP, except for the fact that newbie developers are less likely to create an XSS vulnerable website in ASP.NET.
ASP.NET includes features like Request Validation by default that limits some common script attacks. You can do it yourself in classic ASP, but in .NET it's default.
There may be may security issues. But I am concerned about one thing. It is about SQL injection. Asp.net has provided the facility of parameterized query and HTML encode decode technique. For more information click the link ASP.net security
I am working on a mobile site that uses .aspx for the pages; however, I am transferring information from older .asp pages. These .asp pages are reading database connections, and I am not clear how to convert these into .aspx pages without running into config errors that are unclear to me in fixing.
Is it bad practice to mix .asp and .aspx pages in a site? If not, how can I learn to better understand the conversion differences from .asp database connections to .aspx? This is the only obstacle I have going on at the moment with this site, and I would love to find a solution soon as I've been stuck here for a while.
The site works, but I would like to be consistent with the .aspx set up in pages. I appreciate any help you may have to offer, thank you.
You can absolutely mix ASP pages with ASP.NET pages. I've done it for internal sites where we didn't have time to redesign, but needed to add some functionality. Note that you can't share session state between the two types of pages (I worked around this using cookies) but the two pages can live together in the same web site without an issue.
Often ASP pages will have database connections kept in the global.asa file or perhaps in an include file, or even right within the asp pages themselves. It would be helpful as you migrate functionality to have all those connections in one logical place.
There is no straight conversion to ASP.NET from ASP, and if you don't have much experience yet with ASP.NET it would be worthwhile to explore some samples / tutorials to get an understanding of how an ASP.NET Web site works. There are lots of options for how you connect to your database. Have a look at www.asp.net to learn about them.
You can have the two running together. It's not necessarily a bad practice to mix the two, but here can be some technical things that you'll have to work out. Since it sounds like you're trying to convert a classic ASP site to ASP.NET, if there are not too many pages, I'd probably try to figure out the conversion issues so that all of your pages are running on ASP.NET.
Otherwise if you do want to run ASP and ASP.NET side by side, if your website has session state or authentication and you need that shared by both asp and asp.net pages, then you need to ensure that you have a strategy to handle that kind of stuff. This thread details session management issues to consider when running ASP with ASP.NET, for example: Classic ASP and ASP.NET Integration.
For reasons not in scope of this question I have implemented a .net project in an iframe which runs from a classic asp page. The classic asp site persisted a few sensitive values by hitting the db on each page.
I have passed there variables as xml to the aspx page, now I need to make these values available on any page of this .net site.
I've looked into the cache object but we are on a web farm so I am not sure it would work.
Is there a way I can can instantiate an object in a base page class and have other pages inherit from the base page to access these values?
What is the best way to persist these values?
A few more points to consider the site runs in https mode and I cannot use session variables, and I would like to avoid cookies if possible..
Perhaps I've misunderstood but, if the ASP classic pages were just hitting the db why didn't you just have the ASP.Net pages do the same? That would certainly solve the web-farm issue and is probably why the ASP classic pages work that way to begin with.
We have an old web app written in classic ASP. We don't have the resources to rewrite the app.
I know that asp and aspx pages can coexist in the same ASP.NET web app, but it appears as those you cannot share Application and probably Session variables across these two groups of page extension types.
I was hoping to do new development in ASP.NET and to in theory, convert the Classic ASP pages over as we go.
Is there a way to share IIS variables across these two types of web pages (aside from passing information using the query string and forms fields)?
There is no straigthforwad solution for sharing session variables between classic ASP and ASP.NET. I would recommend you to persist sessions into a database, like it is described in this Microsoft Article. This way both ASP and ASP.NET can access session variables.
Not a direct way. You could consider using a shared database backend for your session state.
You could create a simple table in your DB to store the "session" info in. Both the classic asp and the .net pages could read and write there.
The only ways to pass this data would be GET/POST values, cookies, flat file, or storing the data to the database. There is nothing "Built In" to the .Net framework to do this.
I have seen another solution aside from using the database as shared session holder. I should say beforehand that using the database option is probably much better than this. But...
You can create an ASP page whose only function is to store into and retrieve from the ASP session state. From your ASPX page you can make a webrequest to your ASP page and return any session information in the header, querystring, or even do a scrape of the restulant load. Alternatively you can return an XML stream and make a poor man's web service.
I addition, you could get session state from ASP.NET by doing the opposite and making a .NET page that access session info and returns it.
It's not a good idea and fraught with security problems. I have seen it done is all I'm saying. It's really probably best to rely on the database and possibly pass session ID around.
Well I just have faced this problem, and want to tell you that just were able to solve it in one way. The solution was relatively easy and actually depends on your original development, in my case the system flow requires to log-in in a default.aspx page and after validating the user/password are correct the page Init.asp is executed and exactly there many session vars are created and loaded (actually are just the minimum needed) after that the last instruction redirects the user to mainmenu.aspx and form that page we call .aspx and .asp files.
This solution worked for me just because of the election the original developer made when designed this ASP 3.0 application and as you can imagine I can't retrieve those values in the asp.net pages.
I just went through this. My solution was to wrap it all in a nodejs app. I dole out JWT tokens from .NET web API that have all the users claims encoded in the payload. This token gets stored in a cookie on the client. The cookie will automatically get submitted on each request to your domain so all you need to do is read the cookie value from the header and decode the payload (in ASP.NET and Classic ASP independently). Once you read the contents, you can simply set the session variables to match those that were embedded in the JWT token.
I prefer this method because it has 0 database synchronization necessary and moves your application to OAuth2 openid and away from session.