One of the challenges I have is when running several sub-domains, each one requires it's own user base. If I add on the Forums as a module, this requires it's own user base as well. One of the things that makes sense to me is to have a configurable (at the
ISPAdmin level) way to share the user tables across sites and internally with specialty modules (like the Forums). So, we need to define hard coded roles and their sphere of responsibilities: 1) ISPAdmin - Sets up domain based sites, link sites together (user
base only?) 2) Site Admin - Top level admin for the site, add/edit/delete pages, users, groups, etc. Sets up user store (AD, NT, DB, etc), sets up Authentication Mode (auto, must be accepted, etc), sets up defaults for new pages (read/edit/delete group(s),
admin group, etc) 3) Authenticated - A user that has been authenticated by the required mode 4) Guest - Anyone not logged in -or- not authenticated by an admin (if that was the mode selected) Then, on the other side of the coin we need to think about security
roles that could be added by the site admin. 1) Section Admins - Add/Delete/Update pages, set at a page level and is inherited by any children pages under that page. Admin page is limited to their sphere of responsibility. 2) Section Assistants - Update text
on pages (headers, footers, etc). Otherwise, same rules apply. 3) Cross Site Admins - this type of person can link parts of site A with site B. (need to better clarify this) For Content Management we will need the following roles defined within a section (The
section admin can do this). 1) Author 2) Editor 3) Publisher 4) CM Admin (runs reports, gathers data, etc) Last, we have the groups that can view/add/delete/update content only 1) Member So, what we end up with is an array of user types plus the Member roles
that can be added freely. I can define sites like this: execs.blah.com staff.blah.com www.blah.com - public facing piece on www.blah.com we have this top level menu: Home | Info | PR | Sales User 1 is allowed into the following builtin roles: * Authenticated
(for the public site) * Section Admin - Info * Author - All PR & Sales * Editor - All Info * Publisher - Info/Product #1 and added to the following freestyle roles: * Staff Member (allows access to the staff site - further roles can de defined on this site)
* Board Member (allows access to the execs site - further roles can de defined on this site) Hope this is making sense...
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
It sounds to me that we need to restructure the section tree. Maybe use something like the following.
/ (www.host.com) |- About |- My Company |- Me |- My Projects |- GotCommunityNet |- OmniPortal |- Forums (forums.host.com) |- Staff (staff.host.com) |- Execs (execs.host.com) |- Profile (my.host.com) |- Blog |- Articles |- School Papers (papers.host.com)
Something like that. Then for things like staff.host.com and execs.host.com those sections would have certain roles assocaited with them. So if a person came into the root site with out those roles they couldn't access those sub-forums, but also if a
person went directly to the URL and didn't have access they would also be rejected. Well that is currently how my system works I don't know if that is sort of what you are looking for or what. Let me know.
I agree that this is a way to work around some of the limitations. However, what I'm looking for is a way, especially on a large site, to allow "assistant admins" and the like. I also want a way to *share* the user base across multiple instances. Right now,
the data mapping is like this: Community (1) -- (many) Users Users (1) -- (many) Groups Page (1) -- (many) Groups This means that on my test system, with 7 communities running, I have
7 logins, one for each community. I also run an ASP.NET forums (and the v2 beta) so have 2 more logins for those sites. So, we need the ability to add to the data mappings: Community (1) -- (many) CommunityUsers (many) -- (1) Users Users (1) -- (many)
UserGroups (many) -- (1) Groups Page (1) -- (many) PageGroups (many) -- (1) Groups
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
So you want users to be in user groups? In addition you also want section groups? (sort of like who can view the section and everything under it? Also you want to be able to set a user or group that has access to only change a certain section and all subsections?
In addition you want to ability to define your own authentication? (i.e. authentication plug-in) Are all these assumptions what you had in mind? Also the tree I listed above has many possibilites, because it works pretty much the same way IIS would work. For
example a modified version of the one above. / (RootAdmin) |- Host1 (www.host.com) (SubAdmin1 [Group]) |- My Company |- Me |- My Projects |- GotCommunityNet |- OmniPortal |- Host2
(www.host2.com) (SubAdmin2 [Group]) |- Staff (staff.host2.com) |- Execs
(execs.host1.com) (Joe [User], {Inherit SubAdmin2}) |- Host3 (www.host3.com) (Frank [User]) |- Blog |- Host4
(www.host4.com) (SubAdmin1 [Group]) |- School Papers (papers.host.com)This way you would have all your sites and then they could share all the same users. In addition you could set one user or a group as the admin at different levels. Then you would have the root admin at the top level, but there would be no address associated
with it, unless you wanted it.
Isn't this breaking the community concept a bit? While per-section viewing permissions is a good concept, I don't think it should be handled via the URL. Borrowing from ZOPE, both the framework and the modules can define sets of named permissions (eg, forum-admin,
gallery-add, etc), and roles as usual are merely collections of permissions. This, I think, is a good way to go about business. As for sharing, I think a global user base is a good idea, but I'd opt for community subscriptions, with a user able to carry specific
roles in each community, not dealt with by the URL.
KFarmer, What do you mean by breaking the community concept alittl? I didn't quite understand that. Because as I understood it, it was basically just to give the look and feel of a community. The underlying structure shouldn't matter much at all. It is like
mapping drives in Windows, you can map drive X to the base and the drive Y to a sub folder of X and it still looks like two different drives. On the permission thing that is not a bad idea. Things would have to change a little but it definitly is doable.
Keith is real close to what I was thinking. It should not matter as much how the sites are mapped. It should be based on what users are in which roles and what roles can do what actions on individual pages. Let's see what a possible ISPAdmin screen would look
like: Community Name: Blah's Public Site Primary Domain: execs.blah.com Community Domain: blah.com Community Sub Domain : execs SMTP Server: mail.blah.com Database Quota: 10000 Security: [Internal|v] <-- drop down list (options = Internal/DB/AD/OU/NT/etc)
Users: [www.blah.com|v] <-- drop down list (options = Stand Alone/other sites in DB) Roles: [www.blah.com|v] <-- drop down list (options = Stand Alone/Mixed/User Site) So, with this, I can now create the www.blah.com site and map users and/or roles created
there directly to any other site also created within the application (like sales.blah.com, support.blah.com, etc.) On the roles selection, that would be determined by what was selected in the Users drop down. If Stand Alone was selected, that is the only option
in Roles. If another site was chosen then I could do: Stand Alone - define new roles for this site only Mixed - use the roles from the site Users are coming from *plus* create more roles User Site - only use the roles defined on the site selected for Users.
To answer the question on security modes: Security providers will be built. By selecting the security model the ISPAdmin has control over where Users and Roles are stored: Internal - The same DB as the site is stored in DB - another DB (many companies already
have a stand alone User Database - will need a tool to map data structures) AD - Active Directory, similar to NT users and groups OU - Org Units within AD, another way to group users and objects NT - Non AD, NT authority (users and security groups)
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
Well I don't see any reason why it couldn't be done. For mapping of roles, I would do the following, just create a roles table that contains the roleID and then the PortalID. So roles will only stay under a certain PortalID until they go into Mixed mode where
just another entry is added for the same role and another PortalID. It's not hard to do at all. Also for the users, I say you have a subscription table also. So which ever site the user is signed up on he is subscribed to that PortalID. Then if he wants to
go to another community site they just have to sign in with their Username and Password and then they are automatically subscribed to that PortalID if they weren't already. Well that is how I would tackle these two problems. But do you guys have any problem
with the structure I designed above? I am trying to map out a list of requirements that we need for 1.2 so people can at least start getting ideas.
I don't see an immediate problem with the structure. I'm sure we could design the new engine with that in mind as well. One of the things I'm seeing with an app of this type are the usage scenarios. 1) GCN is installed on an ISP. The ISP adds sites. The clients
can then administer their individual sites. 2) A company or an individual wants the GCN and installs it in an internet/intranet scenario. They would require the ability to share users, roles etc. By going down this road I believe we can develop a more robust
- and configurable - application for others.
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
StarPilot, I can offer a good 90% of what we talked about already. I forsaw most of these problems when I was developing OmniPortal. Also if you look at the code you will still see some reminants of GCN, because I couldn't have got OmniPortal where it is today
if I didn't already start off with a good idea and a good model. But 90% of what we have been talking about adding to the core is already availiable in OmniPortal. This is the last time I say "Oh, OmniPortal can do that", I know you guys are probably getting
sick of it. ;) Anyways... I think we are really putting together a quality system.
Keith: (Perhaps we should start addressing each other as "Q"?) So what your proposing is to allow a community to inherit users and roles from another community? I would actually suggest only inheriting the roles. Then you map Role to User+Community If your
goal is to have single-signon capability, I still recommend having a single, global users store (perhaps a transformed view spanning multiple sources like DB, AD, etc), with a subscription table mapping users to communities. Spanning multiple sources, however,
leads to an ambiguity in storing newly-created users. That can be changed by setting a default user creation site (the internal DB, for example), and providing an admin tool to port the record to another source, such as AD.
Okay Q :) I agree with what you had to say, but I think we should have a roles database but also if the admin wants to enable a feature to make each user their own role. So it works sort of like Windows Auth, where you have roles and users and both can be added.
So say you have the following: UserName: Joe UserRoles: siteX-admin, siteY-admin but what about if on siteZ the global admin doesn't want everybody in the siteZ-admin group to administer siteZ, and then just want Joe to admin it. So you could then have. UserName:
Joe UserRoles: siteX-admin, siteY-admin, Joe So basically each user is it's own role, and this allows us to do everything we have been talking about and still use the role based ASP.Net system that is currently in place. Also the role Joe doesn't have to be
put in the roles table, when authenticated the role Joe can be added at the end of the "real" roles the user has.
Keep it simple. Highly granular security is functionality that could take an enoumous amount of time and effort to design and implement, yet only be useful to a very small number of people. I advocate we keep the basic security design as simple as possible.
We can make it pluggable so what if someone wants more functionality they can replace the core security system with another one if they want to. Here are my ideas for the options I think the master admin should be able to choose from. 1) Each community has
distinct users and roles that have no relation to other communities (same as current GCN implementation). This is the default. This is good for sites that host unrelated communities. It is assumed that the bug with usernames existing in two communities is
solved. 2) Master admin can enable an application wide shared security system. All communities have the exact same users, and roles. Any new user created is created in the master user list and is valid in all communities in the application. All roles defined
are also created in a master role list and can be used in all communities. The only thing a community admin can do is specify which permissions (if any) any specific role has. Community Admins may not delete or modify a user account (the master admin can though).
This setup is good for intranet applications where many communities exist, but they all share the same potential list of users and groups... similar to NT. Optional features for 2): -- Community admins can explicitly block a user being valid. -- Community
admin can define custom site-specific roles while also being able to use the master admin defined roles. These two simple implementaitons cover (guessing here) probably 95% - 99% of all site's needs. Most sites simply don't need complex role sharing, community
trust relationships, and complex ACLs. While they are nice to have, the time and effort designing the system probably isn't worth the number of people that would use the functionality, plus is complicates things for the majority that just don't care and want
simply security setups. Come on... it's a community web site framework, not an operaing system.
"You will be assimilated." Thanks Redd for the comments. Great job, and I do appreciate them. :) I agree - we need to keep this simple, or at least simple enough that we make progress! I like the way Redd explained his examples. Looks like we may have a good
overview of what the security module will provide the engine now. (Notice, that I did not dive into *how* the security module will do it). So, next step here is to start defining the Security Interface. Let's concentrate on the Interface exposed to the Engine.
Once that is defined, creating several different security snap-ins will not be so difficult as we already know what's coming in and going out... :D
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
Right now, in my head, Users, Roles, Security and Authentication are all kinda lumped together. Since Users/Roles *can* be stored anywhere, the storage medium determines the *way* authentication happens. There is, of course, the web.config controlled manner
of presentation and routes into the system but those are more or less for the Presentation Layer to handle. One of the ways, after reading Redd's post again, I've been thinking goes like this: A new user comes to a site (with a shared User and Mixed Roles
base). The user creates a login. Based on SuperAdmin settings the user is either immediatley granted Authenticated status or is put in a "queue" for Admin approval. Now, he goes to a sister site. He can try to login and maybe that action alerts an admin that
person A is requesting access to this sister site - or he is automatically granted authenticated status. A lot of variables can happen through this shared User base. OK, maybe this - he registers on site A. In filling out his profile, a list of other sites
could be presented (depending on what the SuperAdmin setup) and he can simply check a box requesting access to those other sites as well. Regardless of how the user is synched up with a site, the underlying mechanics don't change: * Authentication based on
SuperAdmin settings (DB, User DB, NT, AD, OU, etc) * Each page request checks Role status (isAllowedToView type of thing) * Each page action (Read, Add, Edit, Delete) checks Role status
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
Okay one more question are we going to mostly focus on the engine or the presentation? I think it will be important to define what an engine is and what it should contain in context to GCN.
One of the ways, after reading Redd's post again, I've been thinking goes like this: A new user comes to a site (with a shared User and Mixed Roles base). The user creates a login. Based on SuperAdmin settings the user is either immediatley granted Authenticated
status or is put in a "queue" for Admin approval Now, he goes to a sister site. He can try to login and maybe that action alerts an admin that person A is requesting access to this sister site - or he is automatically granted authenticated status. A lot of
variables can happen through this shared User base. OK, maybe this - he registers on site A. In filling out his profile, a list of other sites could be presented (depending on what the SuperAdmin setup) and he can simply check a box requesting access to those
other sites as well. I feel that all of these are presentation layer things that can be discussed after we get the UserBase down. I have actually worked on a pluggable UserBase model that we can levage off of at
OmniPortal.Authentication and the implimentations of the UserBase
OmniPortal.Components.Authentication. This is how I am Authorizing and Authenticating the users on entering
PortalHttpModule. How the implimentation works is it creates a UserBase from one of the authentication plug-ins, then it sets the Context.User to a custom Principal that takes in the values from both the UserBase and the current Section, so the Principal
can judge if the user has access to the section, and since it is in Context.User the ASP.Net system can use it with out a problem. Sorry this is really technical but it is a good start for what we want to do.
If you are going to build a new security imp, may want to add in page actions for "move" also. Anyway.... the basic idea is that there should be one table for all users, one table for all roles, and one table for all user to role mappings, same as there is
today. The difference is that the "communityID" field for these tables gets set to -1 for shared entries (this lets you have a mix if you want; shared roles and community specific roles both). Anyway, the security system itself could remain ignorant of which
mechanism is used. After all, it will be asking the database for lists of all valid users, roles, and permissions for the given request. The only difference between the two systems I describe is that the database will provide different lists of valid users,
roles, and permissions depending on admin settings.... so you can perform these checks at the stored proc level (the procs building the lists simply read from the app config settings to see if shared security is in use or not). Now... some attention would
need to be paid to "switching modes" but that is another discussion :{
This is how I would design the plug-in part. What StarPilot has is very good, but it is probably more suited as a plug-in than the interface for the pluggable system. Here is what I have for the pluggable interface, please tell me what you think:public
interface IUser : IPrincipal { string[] UserRoles { get; } string[] SystemRoles { get; } bool IsAdministrator { get; } bool IsUser { get; } bool IsSuperUser { get; } bool IsAnonymous { get; } } public abstract class UserBase : IUser { public UserBase () public
virtual string[] UserRoles public virtual string[] SystemRoles public abstract bool IsAdministrator { get; } public abstract bool IsSuperUser { get; } public virtual bool IsUser { get { return public virtual bool IsAnonymous { get { return ! public virtual
IIdentity Identity public virtual bool IsInRole (string role) protected virtual IPrincipal Principal } public class PortalPrincipal : GenericPrincipal { internal PortalPrincipal (UserBase user, SectionInfo section) : base(user.Identity, user.UserRoles) public
bool IsInRoles(params string[] roles) public new bool IsInRole(string role) public bool IsAdministrator public bool IsUser public bool IsAnonymous public bool HasViewPermissions public bool HasEditPermissions public bool HasAddPermissions public bool HasDeletePermissions
public bool IsOwner public new PortalIdentity Identity } public class PortalIdentity : GenericIdentity { public const string AnonymousName = "Anonymous"; internal PortalIdentity (string name) : base(name, "OmniPortal Authentication") { } public override bool
IsAuthenticated }
Ok, let me ammend and expand on my previous post. Above I said take care of list building at the stored procs... I do realise this is only valid in the DB provider. For AD or LDAP or what not, you would do this a little differently. We'd have a Security Core
component that deals with determining when security checks are needed and what kind are needed. This part would not be pluggable and wouldn't change. Then we'd have a security data provider that is pluggable. For the DB based security system though, the security
data provider would be rather simple convering incoming requests from the security core into simple stored proc calls then giving a simple answer back to the security core. For an AD provider though, the component would have to perform much more work internally.
I like where nberardi is headed with the interface. The only change I would make is to drop the properties (isAdmin, etc) in favor of a single method that uses a enum (or string). As far as my post, yes, it was a mix of Interface and Implementation. However,
I sometimes think best when I can see all of the pieces (old and new) and wanted to just get it out of my head. The picture is starting to clear up for me. As far as data structure goes, that is implementation dependant. i.e.: it will depend on the storage
mechanism chosen. To try to put a picture to my thoughts: .----------. | Engine | `----------' .-----------------. | GCN.Security | this is the assembly the Engine uses. `----------------' .---------------. .---------------. .---------------. | DB Provider
| | AD Provider | | OU Provider | etc... `---------------' `--------------' `--------------' These are the different providers. Each of them uses the ISecurity interface so the GCN.Security assembly interfaces the exact same way to each. However, the implementation
of each provider is unique. The SuperAdmin can choose which provider to use. (The ISPAdmin assembly will build this list by querying the bin directory for each type of provider with an ISecurity interface. This way, a new one can be implemented by anyone,
dropped in the bin and the SuperAdmin can now use it. Configuration through existance or absence of a provider!)
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
OK. I was out looking at another MS Application Block and came across this one:
Authorization and Profile Application Block. I'm only 5% through it but it appears to be almost identical to what I have in my poor brain. :)
Keith Barrows
Ad Astra Per Aspera - "To the stars thru difficulties"
I am not sure I understand this Application Block that you keep talking about. Is a Data Application Block the same this is a Data Application Layer. If not what is the difference?
The data application block is one of the MS Patterns and best practices solutions for enterprise development. You can dload from the following address. http://www.microsoft.com/resources/practices/audiences.asp Patterns are basically reusable solutions that
address specific architecture, design and implementation scenarios... i.e. big blocks of funky, bug free code : ) Data Access Application Block ---------------8<---------------- Implements a data access helper component, SqlHelper, which helps execute statements
against SQL Server 7.0 and higher by exposing a set of static methods and reduces the amount of data access code you have to write. V2.0 supports the .NET Framework v1.1. ~~~~~~~~~~~~~~~~~~~ Use it if you are using SQL Server as the database and wish to reduce
the amount of data access code you write. Can use it internally in your own data access classes. Versions of SqlHelper for OleDb and Oracle written in C# are included in the Nile 3.0 sample application. Exception Management Application Block --------------------8<-----------------------
Provides a simple and flexible mechanism for publishing exception information through an ExceptionManager class. Also supports filtering and creating your own exception publishers to publish data to sources other than files and event logs using text and XML.
Also provides a BaseApplicationException class from which to derive, which collects additional environmental information. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use it as the basis for your exception handling framework. Ideal for applications that use exception chaining
or wrapping and pass exceptions up the call stack. Custom publishers can be used to log exception information to shared databases. Aggregation Application Block ---------------8<---------------- A component that dispatches Service Agents to collect information
from various sources for the application. The application then makes requests to the aggregate component and it returns a single XML document of the collected data. It uses the Exception Management Block and can be used with both the Asynchronous Block and
the Caching Block. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use it when your application needs to bring together data from various sources and those sources may change over time. The Aggregation Block serves to abstract the underlying data sources. Asynchronous Invocation
Application Block ----------------------8<------------------------ A component that dispatches requests on background threads and then notifies the application when complete. It uses the Exception Management and Data blocks. This block is meant to be used
with the Aggregate Block and can work with the Caching block. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use it when the data sources your application communicates with may require a lengthy call. Using the Async Block makes it appear as if the application is more responsive
by allowing Web pages to be built incrementally. Caching Application Block -------------8<------------- Allows applications to make requests of a CacheManager object that either returns the data or invokes a Service Agent to retrieve it. Allows items to be
expired from cache and cached data to be stored in a variety of format including SQL Server, memory mapped files, or a Singleton object. It uses both the Exception Management and Data Blocks. Can also be used with the Async and Aggregation blocks. ~~~~~~~~~~~~~~~~~~~~~~~~~~
Use it when you need to cache data in Windows Forms or other non-Web based applications. ASP.NET provides its own cache and so would not typically be required for Web applications. Very useful for improving performance. Configuration Management Application
Block -----------------------8<------------------------- A component that abstracts the location of configuration information used in an application and adds features including encryption, caching, and extensibility. It also adds the ability to both read and
write the configuration data. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use it when your application might require its configuration data to be stored in different locations at different times. Also take advantage of it for encrypting sensitive information. Updater Application
Block -------------8<-------------- A component that can be used to download new versions of applications to client machines (using BITS for example). Includes a manifest to specify all the related files and ensure the entire application is downloaded. Provides
optional file verification and support for custom downloading and verification components. It uses the Exception Management Block. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use it when your application needs to auto-update with new assemblies or when you are writing a service
to provide client machines with updates to a variety of applications. User Interface Process Application Block ---------------------8<---------------------- A base class (ControllerBase) and User Interface Process Manager component that allow you to separate
the logic and state of a user process from the UI needed to collect data and navigate. Includes a set of persistence managers that allow you to save the state of the process in SQL Server, an ASP.NET session, or a custom store. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use
it when you need to implement the same process in different types of applications (Windows Forms, Web forms) or want to allow users to resume a session at a later time. Also ideal for wizard-based applications.
There are some major hurdles that we are going to have to get over inorder to use some of these application blocks, and some don't even apply for what we need. For instance Data Access Application Block only supports SQLServer, we need to suppoort SQLServer
as well as Access. So that is out unless we want to go through and change all their code. In addition they are using XmlReaders, which I am skeptical about, because of the high overhead for anything Xml.
> we need to support SQLServer as well as Access There are versions of SqlHelper for OleDb and Oracle written in C# included in the Nile 3.0 sample application: http://www.microsoft.com/downloads/details.aspx?FamilyID=e6d2cca0-9abb-48cd-bce9-e8beb0847725&displaylang=en
This should suffice and its not a far stretch to build more.. The convenience and design far outweighs the down sides and SqlHelper also supports the MSDE. Other than the Caching block which do you not think applies? Personally I can see invaluable uses for
most of the blocks.
For instance many of them seem like a really overkill. For instance {Configuration Management Application Block} and {Updater Application Block} and {User Interface Process Application Block} and {Exception Management Application Block} Most of them have specific
applications for Module/Display layer stuff. And shouldn't really be included in the core such as {Asynchronous Invocation Application Block} and {Aggregation Application Block} I could see the use of the Cache and Data Access blocks in the core.
Well back on topic of Users and Groups. I think everybody should take a look at
Threats and Counter Measures for Authentication and Authorization, it is really good and should really help out.
Hey guys, I just modifed my core to support authentication much like that of Windows. So now there is a seperate table that are associated with the section. In addition to this I also added the ability for the module to inject it's own permissions that it may
want to give users access to. Basically what I did was reverse the method that is currently getting used. Such as you have columns for each permission, view, add, edit, and delete. And I reversed it and added a SectionsRole table. Which holds the section_id,
role_name, and role_permissions. combination of section_id and role_name is the key. So far this works very well and has greatly expanded what I can do with authentication and roles. If you guys are interested in seeing what I have done you can take a look
at my CVS in a day or so when SF updates it. Well if you have any questions, you know where to find me. :)
Member
30 Points
241 Posts
ASPInsiders
[1.2] - Users and Groups
Feb 09, 2004 05:25 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 10, 2004 08:34 AM|nberardi|LINK
/ (www.host.com) |- About |- My Company |- Me |- My Projects |- GotCommunityNet |- OmniPortal |- Forums (forums.host.com) |- Staff (staff.host.com) |- Execs (execs.host.com) |- Profile (my.host.com) |- Blog |- Articles |- School Papers (papers.host.com)Something like that. Then for things like staff.host.com and execs.host.com those sections would have certain roles assocaited with them. So if a person came into the root site with out those roles they couldn't access those sub-forums, but also if a person went directly to the URL and didn't have access they would also be rejected. Well that is currently how my system works I don't know if that is sort of what you are looking for or what. Let me know.Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 10, 2004 12:33 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 10, 2004 12:46 PM|nberardi|LINK
/ (RootAdmin) |- Host1 (www.host.com) (SubAdmin1 [Group]) |- My Company |- Me |- My Projects |- GotCommunityNet |- OmniPortal |- Host2 (www.host2.com) (SubAdmin2 [Group]) |- Staff (staff.host2.com) |- Execs (execs.host1.com) (Joe [User], {Inherit SubAdmin2}) |- Host3 (www.host3.com) (Frank [User]) |- Blog |- Host4 (www.host4.com) (SubAdmin1 [Group]) |- School Papers (papers.host.com)This way you would have all your sites and then they could share all the same users. In addition you could set one user or a group as the admin at different levels. Then you would have the root admin at the top level, but there would be no address associated with it, unless you wanted it.None
0 Points
87 Posts
Re: [1.2] - Users and Groups
Feb 10, 2004 07:32 PM|kfarmer|LINK
http://www.thuban.org
kfarmer@thuban.org
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 10, 2004 08:00 PM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 11, 2004 02:44 AM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 11, 2004 07:49 AM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 11, 2004 12:17 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 11, 2004 12:52 PM|nberardi|LINK
None
0 Points
87 Posts
Re: [1.2] - Users and Groups
Feb 11, 2004 02:59 PM|kfarmer|LINK
http://www.thuban.org
kfarmer@thuban.org
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 11, 2004 03:42 PM|nberardi|LINK
Member
35 Points
1052 Posts
Re: [1.2] - Users and Groups
Feb 11, 2004 06:20 PM|Redd|LINK
http://www.reddnet.net
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 09:45 AM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 10:02 AM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 11:13 AM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 11:48 AM|nberardi|LINK
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 12:03 PM|StarPilot|LINK
UserUtility: ArrayList GetAllRoles() DataSet GetAllRolesFromDB() DataSet GetAllUserRoles() void AddRole(string roleName, string description) int LoginUser(string username, string password) void GetUserRoles() String[] GetUserRolesFromDB(string username) void SignOut() void UpdateUserRoles(string username, string[] roles) void UpdateRole(string originalRoleName, string newRoleName, string newRoleDescription) void DeleteRole(string roleName) int RegisterUser(ProfileInfo profile) int UpdateProfile(ProfileInfo profile) ProfileInfo GetProfile(string username) ProfileInfo GetProfileFromEmail(string email) string GetPasswordFromUsername(string username) ProfileInfo PopulateProfileFromSqlDataReader(SqlDataReader dr) void UpdateUserQuota(string username, int userQuota) UserInfo: bool IsAuthenticated bool IsAdministrator string Username bool MayView bool MayAdd bool MayEdit bool MayDelete bool MayComment bool MayModerate bool MayRate bool IsInRole(string roleName) bool CheckAuthenticatedPermission(string[] PageRoles) ProfileInfo This is a non-static object that contains properties for all parts of the user's profile (Name, City, etc) RoleType public enum RoleType { ViewRole = 0, AddRole = 1, EditRole = 2, DeleteRole = 3, CommentRole = 4, RateRole = 5, ModerateRole = 6 } - CONTENT - (Basically the code behind for matching user controls)
ShowProfile protected string SkinType protected void InitializeSkin(Control skin) protected void OnLoad(EventArgs e) void ShowNoProfile() Register protected string SkinType protected void InitializeSkin(Control skin) void btnRegister_Click(Object s, EventArgs e) PasswordReminder protected string SkinType protected void InitializeSkin(Control skin) void btnSend_Click(Object s, EventArgs e) void btnCancel_Click(Object s, EventArgs e) EditProfile protected string SkinType protected void InitializeSkin(Control skin) protected void OnLoad(EventArgs e) private int UserID private void btnUpdate_Click(Object s, EventArgs e) Login protected string SkinType protected void InitializeSkin(Control skin) void btnLogin_Click(Object s, EventArgs e) Logout protected string SkinType protected void InitializeSkin(Control skin) protected void OnLoad(EventArgs e) - CONTROLS - (Basically the code behind for matching server controls)
UserLogin protected string SkinType protected void InitializeSkin(Control skin) void OnPreRender(EventArgs e) AlphaPicker void CreateChildControls() LinkButton CreateLetteredLinkButton(String buttonText) event System.EventHandler LetterChanged void Letter_Clicked(Object sender, EventArgs e) string SelectedLetter RegisterForm protected string SkinType protected void InitializeSkin(Control skin) + a whole bunch of Profile properties (FName, LName, etc)
Side notes: * I like the idea of using enums instead of properties (isAdmin, isModerator, etc) * I like the idea of a unified data encapsulation method (simple XML) over using objects to pass data between assemblies and/or layers
Ad Astra Per Aspera - "To the stars thru difficulties"
Member
35 Points
1052 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 12:13 PM|Redd|LINK
http://www.reddnet.net
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 12:30 PM|nberardi|LINK
public interface IUser : IPrincipal { string[] UserRoles { get; } string[] SystemRoles { get; } bool IsAdministrator { get; } bool IsUser { get; } bool IsSuperUser { get; } bool IsAnonymous { get; } } public abstract class UserBase : IUser { public UserBase () public virtual string[] UserRoles public virtual string[] SystemRoles public abstract bool IsAdministrator { get; } public abstract bool IsSuperUser { get; } public virtual bool IsUser { get { return public virtual bool IsAnonymous { get { return ! public virtual IIdentity Identity public virtual bool IsInRole (string role) protected virtual IPrincipal Principal } public class PortalPrincipal : GenericPrincipal { internal PortalPrincipal (UserBase user, SectionInfo section) : base(user.Identity, user.UserRoles) public bool IsInRoles(params string[] roles) public new bool IsInRole(string role) public bool IsAdministrator public bool IsUser public bool IsAnonymous public bool HasViewPermissions public bool HasEditPermissions public bool HasAddPermissions public bool HasDeletePermissions public bool IsOwner public new PortalIdentity Identity } public class PortalIdentity : GenericIdentity { public const string AnonymousName = "Anonymous"; internal PortalIdentity (string name) : base(name, "OmniPortal Authentication") { } public override bool IsAuthenticated }Member
35 Points
1052 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 12:48 PM|Redd|LINK
http://www.reddnet.net
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 01:04 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 12, 2004 01:56 PM|nberardi|LINK
public interface IUser : IPrincipal { string[] UserRoles { get; } string[] SystemRoles { get; } UserType UserType { get; } } public enum UserType { Administrator, SuperUser, User, Anonymous } public abstract class UserBase : IUser { public UserBase () // IUser Interface public virtual string[] UserRoles { get; } public virtual string[] SystemRoles { get; } public virtual UserType UserType { get; } // IPrincipal Interface public virtual IIdentity Identity { get; } public virtual bool IsInRole (string role) protected virtual IPrincipal Principal } [Flags] public enum Permissions { Read, Add, Edit, Delete, Administrate, Write = Add | Edit, ReadWrite = Read | Write, Modify = ReadWrite | Delete, FullControl = Modify | Administrate, None } public class PortalPrincipal : GenericPrincipal { internal PortalPrincipal (UserBase user, SectionInfo section) : base(user.Identity, user.UserRoles) public bool IsInRoles(params string[] roles) public new bool IsInRole(string role) public bool IsUserType (UserType type) public bool HasPermissions (Permissions p) public bool IsSectionOwner public new PortalIdentity Identity } public class PortalIdentity : GenericIdentity { public const string AnonymousName = "Anonymous"; internal PortalIdentity (string name) : base(name, "OmniPortal Authentication") { } public override bool IsAuthenticated }Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 02:01 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Member
30 Points
241 Posts
ASPInsiders
Re: [1.2] - Users and Groups
Feb 12, 2004 02:02 PM|StarPilot|LINK
Ad Astra Per Aspera - "To the stars thru difficulties"
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 15, 2004 02:44 PM|nberardi|LINK
None
0 Points
34 Posts
Re: [1.2] - Users and Groups
Feb 15, 2004 04:43 PM|bentomkins|LINK
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 17, 2004 10:16 AM|nberardi|LINK
None
0 Points
34 Posts
Re: [1.2] - Users and Groups
Feb 17, 2004 11:01 AM|bentomkins|LINK
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 17, 2004 11:12 AM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 17, 2004 11:15 AM|nberardi|LINK
Participant
792 Points
2233 Posts
Re: [1.2] - Users and Groups
Feb 18, 2004 09:09 PM|nberardi|LINK
None
0 Points
66 Posts
Re: [1.2] - Users and Groups
Feb 20, 2004 01:07 PM|Kiliman|LINK