Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
BOOK: ASP.NET Website Programming Problem-Design-Solution
This is the forum to discuss the Wrox book ASP.NET Website Programming: Problem - Design - Solution, Visual Basic .NET Edition by Marco Bellinaso, Kevin Hoffman; ISBN: 9780764543869
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET Website Programming Problem-Design-Solution section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old July 27th, 2003, 02:30 AM
Registered User
 
Join Date: Jul 2003
Location: , , .
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Authentication and permissions (ch. 5)

The authentication mechanism (implementing IPrincipal and IIdentity) stores information about the user's permissions in an array. Where is this array stored at run time?

Once the user is authenticated and his profile is loaded, where is it actually stored? It doesn't seem logical that every call to every page will go to the database and bring up the user's permissions again and again. Is this info stored on the server for the duration of the session and fetched from memory using the encrypted authentication cookie as a token?

If so, what happens in a web farm scenario where each request might be directed to a different server each time?
 
Old January 14th, 2004, 03:26 PM
Authorized User
 
Join Date: Nov 2003
Location: LA, CA, USA.
Posts: 16
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Good point. This might defeat the purpose in high traffic application. Ideally those roles should be saved to the cookie as string with Pipe as separator. "User | Admin | Guest" rather than storing them in runtime array.

Thanks
Musa

 
Old January 14th, 2004, 04:32 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,110
Thanks: 0
Thanked 3 Times in 3 Posts
Default

You can try storing it in a Session variable:

Web-Farm Session State. ASP.NET session state lets you share session data user-specific state values across all machines in your Web farm. Now a user can hit different servers in the web farm over multiple requests and still have full access to his/her session. And since business components created with the .NET Framework are free-threaded, you no longer need to worry about thread affinity.
-From: http://www.asp.net/whitepaper/whyasp...ndex=0&tabid=1


 
Old January 19th, 2004, 06:32 PM
Registered User
 
Join Date: Jan 2004
Location: , , .
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
quote:Originally posted by musa
 Good point. This might defeat the purpose in high traffic application. Ideally those roles should be saved to the cookie as string with Pipe as separator. "User | Admin | Guest" rather than storing them in runtime array.

Thanks
Musa
Doing this opens a huge security hole. If you put authentication or authorization info in a cookie, and it gets sent to the client, then the client can modify the cookie contents, granting himself Admin privileges.

Your code must never trust data that passes out of its control, which cookies do. Store sensitive information in session variables!




Similar Threads
Thread Thread Starter Forum Replies Last Post
IIS Permissions ASPNewbie2 ASP.NET 2.0 Basics 0 December 13th, 2006 09:06 AM
Ch 11 SMTP SendMail Authentication Required sixiron BOOK: Beginning Visual Basic 2005 ISBN: 978-0-7645-7401-6 0 November 11th, 2006 09:57 AM
Permissions w/o server Snib Pro PHP 12 August 11th, 2004 04:54 PM
Ch. 4 & Ch. 12 athena BOOK: Beginning PHP, Apache, MySQL Web Development ISBN: 978-0-7645-5744-6 0 July 23rd, 2004 10:54 AM
Permissions rwalker Crystal Reports 1 June 23rd, 2004 04:33 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.