Role Providers Cache

[Tom]

If you do not cache role provider to Cookies with the
cacheRolesInCookie="True" in your role provider configuration, will it
default to cache to Session. We may have over 200 roles for some users and
I am concerned about the size of the cookie but would like the role cached if
posible. We will be writting our own role provider but would like to do as
little as possible.

Thanks
Tom

 

[Joe Kaplan \(MVP - ADSI\)]

What was the question you were trying to ask? It sounds like you know the
options pretty well.

If you are trying to avoid using session state (always a good idea in my
mind unless it is unavoidable), the cookie does sound like a good idea, but
it could be really big. You could create some sort of compression type of
thing where you have a big bitmap to represent the roles and then just store
the values in the cookie as the representative byte array of the roles. Of
course, then you'd need some code to read and write the cookie in order to
turn those back into friendly representations internally.

Joe K.

 

[Tom]

Thanks for the reply.

The provider we need to write may be a short term once the Web site with
over 200 functions (applications) is rewritten from VB6/ASP to .NET. The
current solution uses a DLL to access all the security roles in a Novell
EDIR. Once the WEB site if fully .NET we may have some flexabilty to use a
Auth Manager Role Provider or use the SQL Role provider (moving the roles to
SQL). But while in transistion it seems like th bes approach is to use a
role provider using the DLL that as the source for the authorization. We
have no way around the 200+ roles since each company(1200+) using the web
site wants to secure the application for their user. Each company has there
own data update and reporting function.

So my main concern was on the cache feature and the cookie was worried we
may hit the limit on the cookie size and wonder if it worth caching the data
in cookies if the data size get large.

Was thinking if we needed to cache the results that the session would be
better ?
Or maybe no cache at all ? Or Cookie but how large is too large ?

Thanks
Tom

 

[Joe Kaplan \(MVP - ADSI\)]

I'm not sure about the max size of the cookie, but you could look that up.

It seems like if you want to use the built-in stuff, the session-based
caching would give you a good security blanket here, with the possible
downside of less scalability and more consideration required in a server
farm environment with out of process session state.

Joe K.

 

[Tom]

Ok think you answered all my question thanks a lot. Looks like we have to
do our own cache using the cache management API. Also have to make sure we
want to manage session. Some issue on how production support wants to set up
in production. We have a farm but not sure if they want to have a cache
Server. But our reverse proxies do have some sort of sticky sessions.

Thanks
Tom

 

[Joe Kaplan \(MVP - ADSI\)]

If you have sticky session support, then you can use in process session
state. If not, you would need to use out of process and either configure
the state server or SQL server, depending on your needs. Getting the state
server up and running isn't really a big deal and doesn't require any
additioanl software, as it comes with ASP.NET.

Best of luck!

Joe K.