I have created a forum, but have now found out that to create more traffic I need to enable anonymous users to add posts.
The idea is that a user who doesn't have an account, can write a post, and fill out the following fields (as you can with stackoverflow):
[UserName][Email][Message]
The datamodel is looking something like this (A bit simplified):
ForumThread/ForumPost: [Id][CreatedDate][Title][Message][UserId]...
User: [Name][Email][CreatedDate][Address][City]...
The question is now, what is the best way to extend the existing datamodel to support anonymous users. Anonymous users don't need all the fields as the regular users e.g. Address etc. The pragmatic way would be to create a UserType describing the different types of users, or I could use some inheritance of a user, but this requires quite a bit of redoing.
Is there a third option I have forgotten?
Add a Role property to the User and have Anonymous and Registered as roles. Leave the properties null that are irrelevant to anonymous users. Although personally, I would just refactor into subtypes.
Create a user in the Users table that is an "anonymous" user, and make anonymous posts under that user's userid.
Related
Hello again every one,
I have a question: I successfully implemented django-auth-ldap, the LDAP users can request successfully my DRF API. But nows, for my projetc needs, I have to define permissions depending of the group.
Indeed, I will have like 12 groups in my app. Depending of the group, I will authorize or not the user to request a given route, BUT even if I defined the global var AUTH_LDAP_MIRROR_GROUPS = True, and saw in my database the are linked to a group (see capture):
Users in database
Groups from LDAP inserted in db thx to django-auth_ldap settings
User linked to the groups defined
But now, I have some other problems: I do not know how to implement permissions depending of the group the user belong. In fact, if a user belong to the group ServerAdministrator, I want to allow him to access to every route accessible, but I dont know where to see this in the received request in my view?
As I understood, I should implement custom permissions I should write programmatically in a User object (which should inherit from django AbstractUser)
If yes, How does it work? Should I empty my whole Database and then let django-auth-ldap insert users and it also will create the given permissions defined inside the database?
Maybe it is not clear, do not hesitate to ask questions if I can be more precise.
Kind regards.
Benjamin
I am in the process of rewriting my PHP website in ASP.NET and writing the membership system.
I understand I can extend MembershipUser to add member specific properties but how can I pass around boolean group information such as Use Search, Edit Posts etc which are not user specific? Is there a framework item I am missing or should I just create a super object to pass this and other settings around?
Essentially what I want it an efficient way to access the users group properties in my controllers.
Apart from extending the MembershipProvider, you can also extend RoleProvider. RoleProvider is in charge of checking to which group a user belongs to, registering new roles, adding user to role(s), etc. To work with roles you will use Roles class which contains a lot of static methods.
In addition to this, each time you hit a Controller, you can query HttpContext.User property which implements IPrincipal. This property has method IsInRole that is used to communicate with RoleProvider to obtain information if a user is in specific group or not.
Also, in order to allow access to controllers or actions you can use Authorization attribute and list specific roles that have access to the controller.
The roles can be stored in a cookie (to cache them) or you can implement Application_AuthenticateRequest in global.asax and initialize GenericPrincipal manually. This object is passed over to HttpContext.User. The constructor of this object accepts an array of roles that are queried with IsInRole method.
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
// Check if user is authenticated
if (HttpContext.User != null)
{
// Extract roles from a cookie if you used FormsAuthentication
// or read them from a cookie or from some other cached location
// Split roles into array of strings
var roles = listOfRoles.ToArray(); // If it is stored in a List<string>.
var identity = HttpContext.User.Identity;
var principal = new GenericPrincipal(identity, roles);
HttpContext.User = principal;
}
}
The above code is not tested. I wrote it from top of my mind. It should give you a pretty good picture how to cache roles and to use them in the most efficient way.
UPDATE: In case that you need more advanced options where each role can have one or more functionality like your "Use search", "Can do something", "Can do that", I would implement the following security logic:
Users
Roles (users belong to roles)
AccessRight (Role can have one or more access right).
UsersRoles table would be for adding users to specific roles.
RolesAccessRights table is where you define specific rights to each role.
User never talks to Functionality. (BTW, this naming convention is just an example, you will follow your naming conventions).
At my last work this is how we implemented the Audit system (it was Web Forms based). However, in MVC you could override AuthorizationAttribute to check user's role and to check if Role has defined access rights. Considering that you have specific security requirement, you would have to use this attribute on every action where you see the need and necessity.
If you plan to implement this logic, forget about Membership, MembershipUser and Roles. Honestly, I don't use these classes any more. I have my own custom security that I implement and which I used in the last 4 projects without any need for update or modification.
UPDATE 2: The security solution that we used was based on custom MembershipProvider and RoleProvider. Thinking about it now, it was a mistake to rely on that because access to AccessLevel table had to be mapped via Entity Framework. Therefore we had to ways to query our security tables.
My suggestion to you would be to ignore Membership- and Role-related classes completely. The first reason is that you would avoid bothering yourself with unnecessary methods and properties when you override the providers. There would be too many methods with throw new NotSupportedException() in the method body.
Suggested implementation
You will need the following tables:
Users - (You need at least three columns UserId, UserName, Password). If you want to hash the password, you might have to store salt as well. Other columns like FirstName, LastName, etc. I would suggest you to store in a different table and link it with UserId. As for UserId type it's up to you whether you would use int or Guid.
Roles - (You need at least two columns RoleId, RoleName). Again, as with UserId, it is up to you which data type you want to use.
UsersRoles - Store UserId and RoleId. You might want to store properties such as whether the role IsActive which is a bit value.
AccessRights - This is where you would store a key of your access right. In your case that is like UseSearch, EditPosts, DeletePosts, etc. Here you should use at least three columns AccessRightId, AccessRightKey and AccessRightDescription. This description field will turn to be pretty valuable if you have a lot of access right keys.
RolesAccessRights - This is where you define to which role you have added specific access rights. Also have IsActive bit value in order to disable the specific access right to a role.
In MVC you would override AuthorizationAttribute. In this attribute you would specify a list of access rights that have access to controller and/or actions. How you plan to do this is entirely up to you, but I would create an enum with a list of values that are the same as AccessRightsKeys. That way you can use strongly typed access rights instead of string based list. For more information about implementing custom authorization attribute have a look at the references list.
Inside of this attribute, you would read User ID and retrieve the roles. Compare the AccessRightsKeys that you specified against the roles (RolesAccessRights table) to see if the role has access right and whether the rule is active.
As for the solution based implementation I would implement Security service layer which communicates with Security-based repository and unit of work solutions. Because you are using MySQL I don't know which ORM you can use or would you have to rely on ADO.NET with OLEDB providers for MySQL.
My usual approach is a top-down approach. I implement from the high up (like Presentation layer) and go down towards data access layer. That way at the end I have only those methods which I really use and there is no redundancy.
Well, I hope this gives you some picture on how to this. As for time it takes, you can do this in about 8-10 hours.
Reference:
Implementing a Role Provider
Roles Class
How to: Create a Custom AuthorizationAttribute
I am working on a ruby on rails application with many types of users. All users will share the basic properties of email address and password, along with the timestamp fields for created_at and updated_at. Other fields will be unique to the type of user (think Employee, Vendor, Manager, etc.) I have been looking into Single-Table Inheritance but that does not seem like the right pattern for this. The other option seems to be to have a User model that has_one of the other models. It is also possible for a User to have multiple types, ie. Employee and Manager could be the same User. I also want to direct the user to a specific page on login, based on what type of user they are. Would this be best done through constraints in the router or a large switch statement on login?
You probably need to define user roles. I suggest CanCan to manage your roles and access privileges.
One way to to implement different fields on a single table would be to use NoSQL (hstore) from Postgres. This is a simple introductory tutorial.
Here is and example of using it with Rails 3.2+
The application is written in Ruby on Rails but the problem I am facing is more a design matter than language related.
the system provides service to a number of users to maintain a registry. So it relates persons to things. As such it has a model called Person representing owners and it has a model called User representing those who manage the registry.
Now a new requirement has arisen to allow People to log in and be able to change personal details which it was not required for the original design.
The question is how to refactor the application to allow this new requirement in?
One easy solution is to create Users for each person who request login credentials and link user to person entity but that is not very DRY as some fields such as firstname, surname etc. are in both classes and in particular, that is precisely the data people will be able to change. Besides User and Person are stored in separate tables.
The other possibility I was considering is to make one to extend the other but having data in separated tables it makes it a bit messy. Additionally the logical extension would be User <- Person as an user is (generally) a person but thinking on the implementation Person <- User is quite a lot easier.
One last option could be to scrap User and move login credentials into Person leaving logon fields empty for those who won't log in and half of the fields empty for those just login in.
Can you think of a better solution?
You could think about how this should ideally work if you were to write the application bottom-up, and then figure out how to make a reasonable compromise between that and your current setup. Here are some generic inputs.
As authentication is involved, you need an "Identity" that can be authenticated. This can be e.g. an email address and an associated password, with email verification.
An Identity can potentially be associated to multiple "Roles" and someone authenticated with the identity can choose which role to perform, e.g. "I am now an administrator" vs. "I am now a regular site user", and the role defines the user's current rights for the logged in identity. Or if you don't need that level of complexity, you can say that an Identity is a (single) Role.
You need some tracking between possible "Rights" and the Role the user is performing. E.g. the simplest setup could be the Identity or Role has some boolean can_edit_profile or can_modify_registry properties.
Whenever a user attempts to perform an action which requires certain Rights, it is simply a matter of looking up the corresponding rights set for the Role being performed by the user, to check whether the user is allowed to proceed.
For your application this may just involve adding a 'can_change_registry' property for your user objects, and check whether that property is True for any code accessing that part of the site.
I am working on a multi-tenant cloud application and considering using E-mail addresses/passwords for general login credentials. However, I may have the same user (same E-mail address) associated with multiple tenants based on the planned sales model for this application. For example, multiple departments in the same company might be separate tenants, or separate companies must be separate tenants. In either case the same user (with same E-mail address) might be a user of these different tenants.
What are possible design strategies for handling such situation?
One approach I am considering is separating creation and update of the user E-mail credentials from the tenants. In this approach a tenant could invite a user (by sending an E-mail) and the user can use the same login credentials for access to all tenants, merely switching between tenants as desired.
What I have typically seen in current web applications is that the user has to have separate E-mail addresses for each tenants, which seems a burden for the user.
Thanks.
Assuming your question is about the technical design (and not the user experience), this is a pretty straight forward solution. Create the users independently from the tenants, and allow for a many to many relationship that represents the "has access to" phrase.
Depending on your chosen backend, there are different manifestations of the design pattern:
RDBMS: Create a user table, tenant table and a user_has_access_to relationship table
Directory Server (LDAP): Place the users into a single OU within the directory, and create the tenants as group objects. The users could then have the memberOf attribute set for each tenant they are able to access.
The LDAP option above has the limitation of overloading the group entity. If you are comfortable enough with LDAP schema definitions, you could just as easily create a tenant object and add a hasAccessToTenant attribute to your user object. Taking this approach would allow you to use groups to represent actual user groups (as the object type was intended to be used).
A more advanced design option would include the creation of a "has access to" relationship between tenants. Adding this, along with the user to tenant relationship, would open up more advanced relationship modeling. For example: a tenant with departments or divisions, allowing users with permission to the top level tenant to automatically "have access to" the divisions.
Using the same credential across namespaces in multi-tenant applications is technically possible. For example, when a user logs in, the application can check across the namespaces and determine which all namespaces he belongs to. There is a possibility, the user may have different levels of authorizations against these namespaces. This is also implementable.
The real problem is the experience the application can offer to such users. They will require a special landing page which will allow them to chose between the namespaces. The chosen namespace should be made quasi-permanent during the session, that is, until the user logs out. ( I am trying to implement this in a new application on GAE/Python27 )
Other possibilities are restricting the user to a single namespace and asking the user to use different credentials against each namespace, which seems to be the prevailing practice.