By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,724 Members | 859 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,724 IT Pros & Developers. It's quick & easy.

Transferring Data Between Applications on the Same IIS box.

P: n/a

I am trying to build a standardized login screen that several different
web application could use. What I would like is for the login screen
to detect where the user has come from. Based on this, code unique to
the site being accessed would run, along with all the code common to
user validation.

The first issue I have run into is:
Redirect does not appear to pass information that can be accessed by
the urlreferrer or via the document object. This is okay, as it is not
the end of the world to pass the information as part of the the query
string. I would like to hide the fact that the user is being directed
to a different "site" if I could. I think there is a way to do this,
but being somewhat new to .net I am not sure what that is. ANY HELP ON

The Second BIGGEST issue I am facing is how to store the fact that the
user session has been validated. Because the login page is a
stand-alone project, it does not have access to any of the other
project's Session or Application variables. Does anyone have any ideas
how I can communicate to the referring application that the session has
been validated. The two options I came up with are

1) Pass the validation back in the query string. This will not work,
however, because obviously all a user would have to do is type in the
query string by hand.

2) Randomly generate the seed for an encryption algorithm and pass it
to the login screen via a hidden control. Before redirecting, the seed
would also be stored in a session variable during the session start
event. The login screen, though it would not have access to the
Session variable, could use the seed passed by the hidden control to
encrypt a string stored in the cookie stating that the user has been
validated. The login would then redirect the user back to the main
application which would use the seed in the session variable to decrypt
the cookie and determine if the user has been authenticated. Once done
this could be stroed in another session variable for use in other pages
and the cookie could be destroyed.

Option 2 right now seems the only real option, other than making a
unique login screen for every application. Option 2 seems a bit more
complicated than might be necessary though, hence I put it to you all
to see if you have a simpler solution. Thanks in advance!

Ryan R

Nov 19 '05 #1
Share this Question
Share on Google+
2 Replies

P: n/a
This is a bit tricky. First off, always think of authentication and
session state as completely seperate. The authentication
communitcation lies in the authentication cookies. Include something
to identify the user in the encrypted cookie value. Then set forms
authentication on all sites and create seperate login pages for each
site. Make sure cookiename is the same across all apps
and set the forms auth cookie domain as the base domain.
In web.config <machineKey validationKey="<MyValKey>"
decryptionKey="<MyDecryptKey>" validation="SHA1"/>, you will need to
generate your own keys and explicitly define them, ontherwise everytime
you reinstall the virtual directory they will be recreated and
different across sites. I typically use lazy load for the session
variables from the identity stored in the authentication cookie. There
are lots of ways to take it from here, but hopefully this gets you


Nov 19 '05 #2

P: n/a
Well, actually, the purpose of this will be to prevent developers from
have to recreate a login page for every application. I think the
approach you are thinking of is a single sign on approach for all
applications. This I don't want. I want a separate application to
handle user authenication for each site uniquely. Any ideas for this
or is my best bet still the encrypted cookie approach?

Nov 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.