Hi
i intend to do a login page for multiple web applications with different access levels. The login page itself is a separate application that stores the access level of the user that logs in.

when the user clicks on the links to the other web applications the login page then checks whether the user's access level is sufficient to view that webpage, if not the user is redirected somewhere else.

as far as i know, each application has it's own global.asa, so is there anyway i can link the applications together and let the login application read the variables stored in the other applications that contain information about the access level required????

any help is greatly appreciated

Are you using Sessions to determine the access rights? If so, you're out of luck. Sessions (and Application variables) can't be shared between ASP applications.

You could work around this in a couple of ways. First of all, you could store the role information for all applications in an (encrypted) cookie at the client. This works well if the number of roles is relatively low.

Alternatively, you can store the unique user ID as an encrypted cookie at the client after the first logon attempt on the first application. Together with this cookie, you also save the roles that are applicable for the current application in Session state.

When your user hits the second site, you programmatically check whether the Session for that application already contains role information. If th role information isn't present, you can retrieve the cookie with the User ID, decrypt it and then use the ID to retrieve role information for the second application.

This way, you have a sort of "automatic logon" on the other sites.

A third option would be to build your own Session state management, that stores Session state in a database. This way, you can share Session variables across applications. Not an easy thing to do, though ;)

Does this help?

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

Imar, Im fairly new to this and don't quite get the answer.

If you remove the global.asa altogether and set the session variables in code, then navigate to another file on the server, what belongs to what application?
How does the server define a "different application"

Dhaywirex,
I guess you in the southern hemisphere like I.
If you don't get a response straight away just hold out till the next day rather than repost, many contributers like Imar are in the northern hemisphere and don't start till late afternoon down here.



======================================
They say, best men are moulded out of faults,
And, for the most, become much more the better
For being a little bad.
======================================

thanks Imar for your help

i was hoping i wouldn't have to use cookies, which is my backup method
anyway, thanks for the help, didnt thought about the 2nd method though

btw, can you tell me abit more about the 3rd way?

hi rodmcleay

yeah, me from southern hemisphere too...
sorry about the repost, i was thinking maybe i posted it in the wrong forum the first time round so decided to post it here, since i search quite awhile and didnt see anyone posting about linking multiple applications

Ha, yes. It's 10 in the morning here ;)

The combination of a global.asa and a setting in IIS determines what an application is. Normally, everything under c:\Inetpub\wwwroot is considered an application, because that's what is setup when IIS is installed.

If you create two folders, like c:\Inetpub\wwwroot\MyApp1 and c:\Inetpub\wwwroot\MyApp2, designate them both as an application in IIS (click the Create button on the Directory tab on the Properties dialog for the folder in IIS), and put a global.asa in each new folder, you now have three applications. The original "root" and the two sub applications. These three applications won't be able to share Session and Application state.

If you're not going to store lots of information in a Session object, you could use SQL Server for Session state (ASP.NET has this built-in). You use a unique ID for each user (you can use their PK in the Users table, or whatever ID you have available) to store and retrieve information in the database. A simple implementation could be something like this:

Public Sub SetMySession(ByVal myUserID, ByVal sessionKey, ByVal sessionValue)
  ' Do an insert in the database here. Pass the key, the value and the user ID
End Sub

You can create a similar method that retrieves the information for sessionKey again.
To make it easier to use, you can make the methods "aware" of the user. This saves you from passing the User ID on each session request. Simply have the methods retrieve the ID from a global variable, a cookie, or the "ordinary" session state.

Personally, I wouldn't go for this method easily. For each session request, you'll need to get into the database, so you might as well access the database for the original data. However, if the data is hard to generate (i.e. you get simple, light results from a very complex and long running query), or the information is retrieved from another location (slow Web service, Active Directory, other network resources), this may work.

Why didn't you want to use cookies initially? ASP uses them for sessions anyway....

Cheers,

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.

thanks once again imar.. this time for explaining about the database thing, and it really dont sound like an easy thing to do

i personally dont like to have cookies on my com, coz of the age-old myth that cookies steal private information, hehe, so i dont wanna use them unless i have to.

btw, its 530pm here and i'm off work now, thanks and bye

Well, in that case, you can't use ASP Sessions either.

ASP stores the unique ID of the user (The ASP Session ID) as a cookie on the client, so for Sessions to work on your site, your client needs to have cookies enabled.

Cheers,

Imar


---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.