+Moose Mob Posted October 31, 2005 Share Posted October 31, 2005 Waiting to see if the "soap box" part will end and the "discussion" part will start. Link to comment
+fizzymagic Posted October 31, 2005 Share Posted October 31, 2005 A session (as mentioned above) is stored on the web server (server) in an chunk of memory describing who the person is that is hitting the site. This information contains the User ID, Email Address and various other information about you. Each time you click a link or a button, the server verifies that you are currently logged in and have the correct permissions to view the page you are navigating to. Doesn't have to be this way with asp.net, raine. This exact situation is what the _VIEWSTATE variable that appears on all asp.net interactive pages is for. The session information can be kept on the client side, so that no server resources are required. If you look at the pages generated by geocaching.com, you will see the variable appear on most of them. Additionally, this field can be encrypted so it is opaque to the user. This feature is probably the only thing that asp.net does better then (or even as well as) the competition. Since the geocaching.com site is implemented using asp.net, I recommend taking advantage of it. Link to comment
Jeremy Posted October 31, 2005 Share Posted October 31, 2005 Caching a page with someone's login information embedded into the page doesn't seem to be a very smart solution to me. Link to comment
+Raine Posted October 31, 2005 Share Posted October 31, 2005 Plus ViewState is a resource hog for both Compiliation on the server to serve to the client, transmission to client and bloat both ways. Link to comment
+Lil Devil Posted October 31, 2005 Share Posted October 31, 2005 But you're already using ViewState on many other pages, so does this mean you need to go fix them, too Link to comment
Jeremy Posted October 31, 2005 Share Posted October 31, 2005 No. I was hinting that it was a security issue. A page stored with all your login information now sits on who knows what machine. Someone restores that page and presses a button and voila! They're you! Sure, you choose "remember me" for a cookie but that is your concious choice and something you can remove by logging out. A viewstate storing that data is not your choice. Of course a better solution has already been recommended, so the point is moot. However, the viewstate does actually store your cache information for after you log back in. Nothing lost - huzzah! Link to comment
+Raine Posted October 31, 2005 Share Posted October 31, 2005 ViewState is added by the Server automagically. If I were to force something to be written to the viewstate I'd have to add that code everyplace I could think of it having to be written and retrieved. Trust me when I say its harder then Fizzy is making it out to sound. Link to comment
+mini cacher Posted October 31, 2005 Share Posted October 31, 2005 (edited) Why is _VIEWSTATE there anyway? A little Greasemonkey script shows me all the hidden form variables and that one is pretty much always there. And during development of... uh... some stuff I was messing with... it was required to be passed around and it changed all the time (which was a huge PITA). It does something important, I just couldn't ever make any sense of it, with it all encoded. I guess its not session info, though with a name like "_VIEWSTATE" it seems like it would be. ooops several posts slid in while I was typeing. Disregard anything already answered. Edited October 31, 2005 by mini cacher Link to comment
Jeremy Posted October 31, 2005 Share Posted October 31, 2005 Why is _VIEWSTATE there anyway? A little Greasemonkey script shows me all the hidden form variables and that one is there pretty much always. And during development of... uh... some stuff I was messing with... it was required to be passed around and it changed all the time (which was a huge PITA). It does something important, I just couldn't ever make any sense of it, with it all encoded. I guess its not session info, though with a name like "_VIEWSTATE" it seems like it would be. This is getting way off topic. Viewstate can be looked up on google. Link to comment
+Raine Posted October 31, 2005 Share Posted October 31, 2005 Technical but worth the read... http://www.asp101.com/lessons/viewstate.asp Link to comment
+mini cacher Posted October 31, 2005 Share Posted October 31, 2005 Sorry, I was just trying to follow along. Fizzymagic made it sound like it was a possible way to get what the OP was demanding. Thanks for the link raine. Back on topic... I've personally never experienced the problem that the OP has explained. But perhaps that is because I use the "remember me" option and the external editor (mostly for spelling reasons but also for easy backup). But I won't ever stand in the way of progress, specially when it has no effect on me. Link to comment
+fizzymagic Posted October 31, 2005 Share Posted October 31, 2005 (edited) No. I was hinting that it was a security issue. A page stored with all your login information now sits on who knows what machine. Someone restores that page and presses a button and voila! They're you! Luckily, _VIEWSTATE can be encrypted on the server side so that it is opaque to the client. Microsoft did a reasonable job of the security on it. But that is off track. Sorry for the derail. I actually believe that the "problem" is really not a problem at all; a little note urging people to save their work would fix it easily. I cannot imagine working on a cache description for 40 minutes without either previewing it somewhere or saving it, either of which solves the problem. Edited October 31, 2005 by fizzymagic Link to comment
Jeremy Posted October 31, 2005 Share Posted October 31, 2005 No. I was hinting that it was a security issue. A page stored with all your login information now sits on who knows what machine. Someone restores that page and presses a button and voila! They're you! Luckily, _VIEWSTATE can be encrypted on the server side so that it is opaque to the client. Microsoft did a reasonable job of the security on it. But that is off track. Sorry for the derail. I'm not disagreeing with you there. It is the use of Viewstate to store login information that scares me when the page is stored on a machine. Session state at least expires on its own making the page worthless for validation. Link to comment
+Mopar Posted November 1, 2005 Share Posted November 1, 2005 I actually believe that the "problem" is really not a problem at all; a little note urging people to save their work would fix it easily. I cannot imagine working on a cache description for 40 minutes without either previewing it somewhere or saving it, either of which solves the problem. In which case the "problem" was already fixed ages ago! "Problem" solved! Can we all go home now? Link to comment
+GeoJunkie Posted November 1, 2005 Share Posted November 1, 2005 Thanks, Jeremy, for taking the time to look at implementing what I know is a tough nut to crack! And thanks, raine, for spelling out the details of what happens when a session expires (those were the details I said I wasn't going into in an earlier post). The ironic part was that the OP identified two problems: one about the 40 minute timeout and the other about how gc.com doesn't have a mechanism to remember you when you've logged in. He was wrong on the second count, and if he'd used the option, he wouldn't have the first problem! (Something I didn't realize until Jeremy pointed it out). Sometimes people just need to pay attention to the site they're using. OK, off my soapbox now. Thanks for letting an old web designer dust off some of his ASP knowledge! Link to comment
Recommended Posts