Home/ Questions/Q 169251
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T12:35:50+00:00

I have a web application that once signed in, personalizes almost all pages. I

  • 0

I have a web application that once signed in, personalizes almost all pages.

I want to be able to have some very specific pages locked down with SSL that may have sensitive information. From what I have been able to find, once you sign in via an SSL sign in page (area of the web site), the session information which I use to store a lot of personalization and user credentials is not available to the non SSL portion of the web site since they are considered 2 seperate applications.

This MSDN document pretty much says what I am talking about: MSDN Doc

Note: If you use this type of site structure, your application must not rely on the user’s identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.

I am also not using forms authentication. When a user signs in a session object is made storing their credentials including their IP. If this session object exists for a particular user with the same IP then they are considered ‘signed in’ and the personalization features are enabled.

So my question is, are there any work arounds to this so that say my sign in page and some other page are using SSL, the reset of the site is not, and all pages have access to the same session variables?

If not can anyone suggest any other methods of accomplishing the same type of personalization features?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. We have decided to not go with SSL in those few pages that required them. We looked at other web applications that did similar things and they do not use SSL. We are not really protecting anything that would be all that useful for a malicious user to go through the trouble of stealing anyways.

    One option I did consider before the decision was made to remove the SSL was to store a user’s session on the application’s web service interface. Every page call would access the web service to access the session information. This would be enforced on every page call to ensure the session stayed active. I didn’t do too much investigation into using this solution before the SSL decision was made so there could be many draw backs to this solution, especially having to make extra calls to the web service with every server hit.

    • 0