Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
session variables
- Thread starter jkl
- Start date
jkl, I think you're in trouble. Sounds like every out has insurmountable implications for you. I don't know how you could make the db method work unless you have some value that follows the user around the site. I mean... how else do you know who they are? Contrary to many ppl's beliefs, there's no magic involved in programming, and therefore, I see no way to do it w/o the querystring method to keep track of who's who.
:-(
:-(
- Thread starter
- #22
yeah, the session route is pretty much all but closed.
i'm now onto a cookie solution for this. having a fwe issues with the cookie expiry (see other post), but at least i can read the same cookie from different apps and from ASP pages. so right away, i'm miles closer than i was with sessions.
well, back to the salt mines...
i'm now onto a cookie solution for this. having a fwe issues with the cookie expiry (see other post), but at least i can read the same cookie from different apps and from ASP pages. so right away, i'm miles closer than i was with sessions.
well, back to the salt mines...
Yeah, you guys are right: the db idea wouldn't fly.
So why not this:
Since the purpose of the "login" seems to be just the customization of what they see, why not:
1.User logs into page
2.UserID is assigned to a querystring variable and sent to
the start page of the other application
3.THAT application grabs the querystring variable, and
sticks it in ViewState for that page.
4.Every time the user goes to a different page to view an
article, the userID is thrown into a session variable,
the new page loads, the username is grabbed from teh
session and thrown in to viewstate for THAT page, and
the session variable is destroyed.
If you do it this way you:
a) don't need query strings
b) use sessions, but not in a way where you'd have 100 of
them floating around all at the same time (since they're
always being created and destroyed only when moving to a
new page
c) the userid is never seen as it is hashed in the source
returned.
Now, before anyone jumps down my throat, yes the Viewstate is NOT super secure (there's a whole thread debating this topic), but if the userID is used ONLY to determine customization of the pages, I couldn't see how exposing it would hurt.
And I still say that if you have a page that hashes the Viewstate on top of the encoding that occurs, its pretty secure, but I'll leave that for the other post.
jack
So why not this:
Since the purpose of the "login" seems to be just the customization of what they see, why not:
1.User logs into page
2.UserID is assigned to a querystring variable and sent to
the start page of the other application
3.THAT application grabs the querystring variable, and
sticks it in ViewState for that page.
4.Every time the user goes to a different page to view an
article, the userID is thrown into a session variable,
the new page loads, the username is grabbed from teh
session and thrown in to viewstate for THAT page, and
the session variable is destroyed.
If you do it this way you:
a) don't need query strings
b) use sessions, but not in a way where you'd have 100 of
them floating around all at the same time (since they're
always being created and destroyed only when moving to a
new page
c) the userid is never seen as it is hashed in the source
returned.
Now, before anyone jumps down my throat, yes the Viewstate is NOT super secure (there's a whole thread debating this topic), but if the userID is used ONLY to determine customization of the pages, I couldn't see how exposing it would hurt.
And I still say that if you have a page that hashes the Viewstate on top of the encoding that occurs, its pretty secure, but I'll leave that for the other post.
jack
- Thread starter
- #24
jack,
your idea would work, EXCEPT:
2. they want to offer an "remember me" feature which allows the person to "auto-login" when they come back to the site. so that they can go to any of their custom pages without loggin in. therefore, there is not one gateway into the "custom" app.
4. all the articles (200+) are currently standard .ASP pages and are not part of any .NET application, so therefore viewstate would not be available.
your idea would work, EXCEPT:
2. they want to offer an "remember me" feature which allows the person to "auto-login" when they come back to the site. so that they can go to any of their custom pages without loggin in. therefore, there is not one gateway into the "custom" app.
4. all the articles (200+) are currently standard .ASP pages and are not part of any .NET application, so therefore viewstate would not be available.
What format are the articles in?!
Are they just text that gets pulled from teh database? Are they HTML files? There is a way that you could get the "standard" asp files to show up and be part of the .NET app (and just so I'm clear, the login and the article viewer are BOTH .NET apps right?)
And the auto login thing isn't a big deal, although you'd still need a cookie. However, you could get the cookie on the initial page request, and stick it into the session from there; that way, you'd cover both ways of accessing the site. Could you just use a cookie? Sure, but as far as I know cookie's are page specific, which means that unless your two apps are on the same main url, they can't read each other anyway. This way, you don't have to write two sets of code (one for sessoin from the login, one for cookie from direct access), and it all works
BOOYAA (well, in theory...and I could be wrong about the cookie thing...and dammit, its 5:30 and I want to go home!)
But let me know what format your articles are in.
jack
Are they just text that gets pulled from teh database? Are they HTML files? There is a way that you could get the "standard" asp files to show up and be part of the .NET app (and just so I'm clear, the login and the article viewer are BOTH .NET apps right?)
And the auto login thing isn't a big deal, although you'd still need a cookie. However, you could get the cookie on the initial page request, and stick it into the session from there; that way, you'd cover both ways of accessing the site. Could you just use a cookie? Sure, but as far as I know cookie's are page specific, which means that unless your two apps are on the same main url, they can't read each other anyway. This way, you don't have to write two sets of code (one for sessoin from the login, one for cookie from direct access), and it all works
BOOYAA (well, in theory...and I could be wrong about the cookie thing...and dammit, its 5:30 and I want to go home!)
But let me know what format your articles are in.
jack
- Thread starter
- #26
- Thread starter
- #28
it's not so much "custom look".
here are the features (hospital website):
my articles - allows them to log the many articles they want to keep reference of
my appointments - add/edit/remove any appointment they have coming up
my prescriptions - keeps track of prescriptions and renewal dates
my diary - personal diary of stuff like, illnesses, accidents, etc.
here are the features (hospital website):
my articles - allows them to log the many articles they want to keep reference of
my appointments - add/edit/remove any appointment they have coming up
my prescriptions - keeps track of prescriptions and renewal dates
my diary - personal diary of stuff like, illnesses, accidents, etc.
Ahhh, now I get it:
So depending on whether or not that doctor, or whoever, has personal access to that article should see it. Gotcha.
k, easy way to show the html pages in one aspx page:
Create an aspx page, and put an iframe in it. Then, when the ueer wants to see a specific html page, you just show it in the iframe "window". You never need to redirect to another page.
That solves the "passing the userid to the page" problem.
However, if they want the ability for hte site to "remember them", then you'll need to use a cookie. Which, of course, means that not all members will have that feature unless they all enable cookies.
And I know it won't change anything, but your manager made a bad decision. It would have been better to create this site as a portal, with the different apps (articles, appointements, etc.) as modules within the portal. The design he settled on is bad, IMO.
Jack
So depending on whether or not that doctor, or whoever, has personal access to that article should see it. Gotcha.
k, easy way to show the html pages in one aspx page:
Create an aspx page, and put an iframe in it. Then, when the ueer wants to see a specific html page, you just show it in the iframe "window". You never need to redirect to another page.
That solves the "passing the userid to the page" problem.
However, if they want the ability for hte site to "remember them", then you'll need to use a cookie. Which, of course, means that not all members will have that feature unless they all enable cookies.
And I know it won't change anything, but your manager made a bad decision. It would have been better to create this site as a portal, with the different apps (articles, appointements, etc.) as modules within the portal. The design he settled on is bad, IMO.
Jack
- Thread starter
- #30
no go on the iframe as this needs to be universally compatible withh all browsers.
oh man, don't talk to me about bad design. the entire website structure is crap. when i started working here 2 months ago, i tooko one look at the directory structure and said "hey, would anybody mind if i scrap the entire thing and do it right?"
still trying to convince the manager that he's wrong. hopefully, i'll still have my job.
oh man, don't talk to me about bad design. the entire website structure is crap. when i started working here 2 months ago, i tooko one look at the directory structure and said "hey, would anybody mind if i scrap the entire thing and do it right?"
still trying to convince the manager that he's wrong. hopefully, i'll still have my job.
![[bravo]](/data/assets/smilies/bravo.gif "[bravo] [bravo]")
Mark- Status
Similar threads
- Locked
- Question
- Locked
- Question