umm... NO
The second application has an entirely different set of session variables because uh huh you may have guessed. It is a second session! That'l do donkey, that'l do
Mark
AND Application variables are not available to another application. Session variables are not avaialable to other Sessions in the same or any other application.
If you did have information that you wanted to share between apps, you could set up a structure with whatever database you're using, assuming that both applications would have access to it.
i.e. You could set up a Shared SQL Server database, which App1 and App2 both have access to.
Of course, if you're thinking more of a "I have one webpage, and I want the second webpage to use the same variables", then you're looking at passing the values through the querystring, and assigning those values to session vars in the new app on arrival (query string info isn't the most secure way to send info, so thats a consideration too)
so even if i use the asp stateserver method, i cannot share session variables?
I have one application that does user registration and login. I have another application running that serves up customized pages based on the user's UserID. I want to be able to pass the UserID to every page on the site using session variables. Is this impossible?
Do they have to be seperate applications? Why not just combine them into one app with different components:
- a login component
- a content generation component
They're separate applications because different people have ownership of each module on the site. I suggested creating them as different components to the same application, but the Manager disagrees. So there are no server wide session variables like there used to be with standard ASP?
I'd love to have words with your manager. you might want to let him know that managing who gets to see what pages (i.e. what my company is doing with a large member portal) isn't that hard to pull off, and is actually made harder by having multiple apps for one page.
Regardless, no, to my knowledge there aren't server-wide session variables. The session variables only survive the current session. Now, with that said though, you should test that theory out and try to access a session variable accross the application pages just to make sure. But to my knowledge, since they're in seperate virtual directors in IIS, no, they can't be shared.
But you could go the database route. All applications would have access to a database table that was in charge of maintaining state across many apps on the same server.
You could even plug in the sessionID to the table(s) if that info is important at all.
is i go the sql server route, how does a visitor share his info from one app to the other?? how do i identify him as user xyz, from application "Registration" as user xyz within application "Customized Center".
I also need to ne able to share the user's ID within several dozen standard ASP pages that are currently on the site.
Basically, we have dozens of articles on our site, that are .ASP pages. We want to give the user the ability to "save" the article into their "My Articles" section.
Also, when I mentioned "ownership", I meant it in terms of development. I'm developing the "My ..." stuff and another developer is doing the "registration/login" and another ..., and so on and so on.
Well, I assume each user has their own ID, yes? If so, then you'd just use that to identify the field in the database as belonging to that user. If you don't, then you'll need to create one. I don't see any other way to do it.
This will also meld quite nicely with your need for existing asp pages to use this information, too, which would not be an option with asp.net session state.
still confused. yes each user has a unique ID, but how does the server know which session/visitor belongs to which ID? How does it associate a certain surfer with that ID? There's got to be some kind of correllation in retrieving the visitor's ID from the sql database while they are surfing.
Once I login, you use a classic session variable to hold:
session("userID" = 123
Then, I view article1, and tell you I'd like to save it. At that point, you make an entry into table, tblArticles, and it would looke like this:
userID | articleID
--------------------
123 | 1
Unless I'm missing your point completely, that should wholely solve the problem. At that point, if I go and log back into another application, then my userID is still 123, right? So you go grab:
SELECT articleID FROM tblArticles WHERE userID = 123;
And typically, I'll have a nice handful of them in there.
If you're trying to uniquely identify a user w/o the use of a customized id, i.e. one that I would sign up for, then I don't see how you could do that. The only way would be like I've described.
i can work out the entire userID --> articleID relationships just fine in the tables. what i'm having trouble with is tracking userID across pages.
i.e.
- new visitor
[no userID]
- logs into "login app; .NET"
[session("userID"=123]
- random surfing on the site
[session("userID"=123]
- viewing articleXYZ.asp
[session("userID" no longer available, it's an ASP page, not ASPX]
- go to "My Articles app; .NET"
[session("userID" is empty because it is a separate application from 'login' which first supplied the value for session("userID"]
how do i get the session("userID" value to persist across two different .NET applications, 'login' and 'myArticles'; as well as the currently existing ASP pages?
I was afraid of this. I know that query string would solve a lot of these issues, however, the problem with that is, there are over 100 articles, each is a separate .ASP page, with 3 times as many links to these articles.
The logictics of passing the userID from one page to the other, across multiple .NET applications and hundreds of other .ASP pages is prohibitive of this method.
I wish I could scrap the entire site, and start from scratch. Tell me boss "Hey boss, gonna shut down the website. Re-write everything into one .NET application and roll it back out in... 6 - 8 months. Okay?"
HAH! If YOUR users are anything like MY users, THAT won't fly!
Your best bet would really be to use the database idea, since that would mean that everybody would get the customized versions.
In a perfect world, everyone would be geeky like us. Mind you, I guess that would mean we'd be out of jobs...and besides, someone has to look over the little people
*phone call our office recieved this morning from a client:
"Yeah, um, it says to enter a password, but I looked through the manual that came with the computer and there's no password"
/me shakes his head
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.