Okay, it’s an established fact that the Session object in ASP has no relation to the Session object in ASP.NET.
My question is this: If I have an ASP page, and it calls an ASPX page, which then does a Response.Redirect to another (or the same) ASP page, will the Session variables from the original ASP page be preserved in the final ASP page? Does anybody know the answer, or do I need to experiment and see?
will the Session variables from the
original ASP page be preserved in the
final ASP page?
Short answer: yes.
This is no different than if you left a page on your ASP site, used that browser window/tab to go to another site like Google, then came back. Your session will be preserved as long as it hasn't timed out or been collected, or any of the other standard things that can happen to invalidate a session.
The ASP and ASP.NET apps are effectively separate applications - almost separate sites, even if they live in the same folder structure - that happen to be running on the same server. They can't share data (without jumping through some hoops like storing things in a database) and aren't aware of each other.
One way to share session variables between asp and asp.net is: http://www.eggheadcafe.com/articles/20021207.asp
I don't believe your session variables will be destroyed unless you either close the browser or clear the session via code.
Yes, the session will exist in asp classic in most circumstances. A few things to consider though:
If the classic pages are not requested again before the SessionTimeout has been reached the instances will be destroyed
If you're running on IIS 7 and redirecting between SSL and non SSL pages there may be different sessions in classic depending on the site configuration properties
Related
Some part of my site is Asp and the other is Asp.Net.
I use session to save the information of current user in Asp pages.
However,the session is lost on redirecting to an Asp.net page.
Sometimes,the session would be saved in the first redirecting Asp.net page.
After a while, I click a button and find that session is still lost.
I am really confused about this situation.
How could this happen?
ps:
1.I have checked the time-out configuration, it seems to work well.
2.The cookie configuration in brower looks normal.
ASP and ASP.NET do not share Session state. They are completely different systems.
If you want to share Session state somehow between the two systems, you can use the method outlined in this article: http://msdn.microsoft.com/en-us/library/aa479313.aspx
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
We have an extensive classic ASP site, and we're looking to upgrade to ASP .Net (most probably the latest version). Obviously upgrading all the pages at once would be a leviathan task, so we're only looking to write new pages (and page rewrites) in ASP .Net at first.
There are two obstacles to doing so:
I have no idea how to access classic ASP session data in ASP .Net. This would only have to be set up once, as it is never modified by any page other than the login page. I'd prefer to have to make minimal changes to the classic ASP login page, but that's only a small preference.
The ASP and ASP .Net sessions would have to timeout at the same time, to keep the version difference seamless.
Could anyone offer any help, please?
Thanks in advance.
We faced the same task (not fun). Since Asp.Net session and Asp session can't be shared, we used a combination of methods, each appropriate to the situation.
In some cases, we used cookies instead of session.
In others, we set up automatically posting forms so that if a user's session information was set in a classic ASP page, after the session info was set, we redirected to an Asp.Net page that read in query string parameters and used those to set the same session variables for Asp.Net. Then once the Asp.Net page set the same variables, that page did a redirect to whatever page the original login page previously pointed to. The same worked in reverse.
So, in the second scenario, an example flow would have changed from:
User tries to access some protected
content page -> redirected to login
page -> logs in -> session info set
based on login success -> redirected
back to content page.
to
User tries to access some protected
content page -> redirected to login
page -> logs in -> session info set
based on login success -> redirected
to a .net page, passing along login
credentials, etc. -> aspx page sets
session info and then immediately
redirects back to content page.
We knew it was a hack, but it worked in the short-term until we could get the sites all converted.
There might be a better way of doing this using newer IIS settings (must admit I've not kept up to date on what new goodies IIS7 can do). But you could do a XMLRequest from your ASP login page to a ASP.Net page. You could either pass through the settings you need in the Post data or have the .net page populate the session data itself if the logic is simple enough. The .net page would then return you a .net session id in the cookie, you need to set this in the ASP users cookie collection so that that user has both a .net and Classic ASP session cookie.
That would do it.
I implemented this a few years ago by using a database.
Microsoft have a pretty good article on it, though it's a little old at this point.
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.