As a requirement our team has to implement session management for our application, redirecting users to the login page on session expiry. The problem is the website is a mixture of classic asp pages, .net web forms and asp.net mvc.
To keep the .net session alive we can use http GET requests to a dummy controller method that will redirect to the login page if the session has expired.
Because there are a considerable amount of page in the application it would be good to avoid having to put an include file on each page to refresh the .net session on each page load. Also for each ajax request made from classic asp we want to refresh the .net session.
An ideal solution to this would be to intercept each request made to the server, pass them through the dummy controller method to refresh the .net session, redirecting the user if the session has expired. I have looked at creating an ISAPI module for this as a possibility but am still unsure of the workload involved in creating such a module, or if I can create the desired behavior.
Is anyone in a similar situation or have a concrete solution to this problem?
Related
I am trying to apply single sign-on to legacy classic asp applications and asp.net applications. I have created a asp.net login page for all aplications. I can successfully pass the authentication ticket from new login page to the old asp.net application and share the session using sql server. However, I cannot do the same thing for class asp applications. Even though I have logged in to the new asp login page, it still redirects me to the new login page when I go to the classic asp applications. I have already checked that their machine keys are the same. The classic asp applications are some .asp pages and html files without web.config before. I added the web.config file to the folder by myself. I can see the machine key in the IIS manger so I think it is reading the file.
Classic ASP and ASP.Net use a different session state object, therefor you're not logged in into your classic ASP site.
There is a possibility, it's kind of a hack. I used it once and it works pretty well. Please have a look at this blogpost to see if it fulfills your needs. It uses the ASP session cookies from .Net in asp classic to call a .Net page that returns session (login) data:
http://devproconnections.com/aspnet/share-session-state-between-asp-and-aspnet-apps
I am attempting to implement a claims based solution into an application. I have an MVC/Classic ASP application, as well as an STS. After authenticating with the STS, I can see the AUTH_USER server variable from my MVC pages. However, this (as well as AUTH_TYPE, LOGON_USER, etc) are not visible in my Classic ASP pages. I would like to be able to test against a server variable that a user is in fact authenticated on the server. If possible, I could read the claim created by the STS to validate the user with my classic ASP pages (not sure if that's an option)
Basically I need a way for my classic asp pages to know that the user is valid when I am logging in via an STS.
Thanks!
we are developing into an asp classic application introducing new asp.net pages.
The session variables are shared through the login.asp, everything works fine...
The problem that we are facing now is that the asp classic session expires meanwhile the user is navigating the .net pages and tries to go again into an asp page... the session in asp has expired because the user has been browsing for more than 20 minutes the aspx pages.
Thanks in advance
Ariel Gimenez
May be you can keep your Classic ASP session alive when a user browse in a ASPX page by:
adding a hidden iframe in your ASPX page that load an ASP Page
' aspx page ....
<iframe src='keep_session.asp' style='display:none'></iframe>
OR use an AJAX post from your ASPX page every 10 minutes to an ASP page to keep the ASP session active
I think you can find interesting:
http://msdn.microsoft.com/en-us/library/aa479313.aspx
update
I think this is the key:
"The native ASP session can only store session data in memory. In order to store the session data to SQL Server, a custom Microsoft® Visual Basic® 6.0 COM object is written to manage the session state instead of using the native session object. This COM object will be instantiated in the beginning of each Web request and reload the session data from SQL Server. When the ASP script is finished, this object will be terminated and the session state will be persisted back to SQL Server."
Do you retrieve asp session from db too?
I can think of two ways around this:
Increase the session timeout setting to be longer then 20 minutes.
Add a redirect page between common pages of the .aspx navigation.
This would redirect to an asp page, and then on to the correct destination, ensuring the session object didn't timeout.
We have a WebForms+MVC 1.0 application where the WebForms site posts an encrypted string to an action in the MVC site which then displays a details view. However in our (clustered) test environment, the post from Webforms can take close to a minute before displaying the MVC view. The MVC action makes a WCF service call to get customer data from an Oracle database. This "slow post" effect only occurs when a user access the application for the first time - the second time around the response times are fast. Any ideas what could be causing this initial slow response time? Does it have to do something with the MVC routing? We don't experience this in our dev server environment.
Thanks
Are you sure that the MVC application is up and running when the first request comes in? The delay might simply be its load time.
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.