The standard edition sets up two user types; admin users and shop users. I'd like to have only one user definition for the entire application; is it possible to remove the admin users and have all the user accounts under one user type (with proper role mapping and ACL)?
Related
I need a help, to find out the best architectural pattern to implement a feature.
We have an application that manages users access to a SalesForce platform. We can create a user, read the roles created in SF and append the user roles from our app and send the change to SF...and some other features not relevent in this question's scope.
We added a new concept to our app, to handle the growing number of SF users we manage. We add a profil concept. In few words, we create a profile with some roles for example DEV_PROFIL. We apply this profil to all the developer users. and we modify each user in Salesforce based on the roles in his profile.
From backend pov, I have a profile index, and a user index and a one to many relation ship. ( one profile can have many users ).
My question is the following :
How I can keep track and keep the user's roles synced with any change I can append to the profile.
Ex : Let's suppose I had 3 roles in my DEV profile. And 100 user have this DEV profile. No I added two new roles to my profile. How can I be sure that 100 users roles are synced after my change ??
PS : Salesforce does not know about my profiles, all he knows is the roles.
I have three roles: admin, instructor (combination of teacher and course creator) and student.
I created a child theme based from clean theme. In my child theme, I customize the layout of the login page. In my login page, there are three buttons: Login as Admin, Login as Instructor and Login as Student.
How can I force the login to be as specific role? I did check out the /login/index.php but I'm having a hard time understanding the flow of the login process.
For an additional info, the dashboard content and design depends on what role the user logged in.
First, San is wrong. There are very much global roles in Moodle. You can access these under:
Site Administration -> Users -> Permissions -> Assign system roles
Second, you talk about 'forcing' a role when you login. This makes no sense in Moodle terms. This is how Moodle works:
Create a user.
Assign them a system role (by default they will be under the role 'All Users')
Login as that user and they will have that role.
Why bother creating three different login buttons? All you need to do is create three accounts, each with different login details, and assign them each a separate role.
If this does not answer your question please give me more details on what you are trying to achieve?
First, there is no global role in Moodle for any user.
User roles are assigned to course level in Moodle.
For dashboard content and design you can check user course level role and show data as per user role.
If a user is a student in any course then, I consider it as a student and show data related to a student only for a course in which user is a student.
I am facing a problem trying to develop an application in Yii (v=1.1). Client wants the application to has multiple databases (one per his customer). That means that we will have unknown number of databases. Also He wants to have only one user authentication system - regard of it, users would have the choise (and the privilleges) to belong in many databases. So I am considering about the way which it could be developed.
Do you have faced something like this?
Well you should first better define your goal because it is not that clear to me what you want to accomplish, but how I see it.
Decide where you want to store the users:
Should the same user be able to connect using the same login info to two different customer databases?
Do you need to manage all users of all customers from one single place?
You could have the following situations:
Store users only in one common database, not in customer databases:
when logging in tell Yii to use the "common" database for the User model
you could have also a common application that handles user management
you could also provide the customer with the possibility to manage his own users
you could either have a "customer" field in the Users table to indicate to what customer it belongs, or you could have a "users_customers" table and after the login screen prompt the user with a "choose customer" screen, so one unique User can login to multiple Customers
Store users only in the customer databases:
if you don't need for a common place to manage users, or don't need to share them between customers, simply have a User table in every Customer database, this way user "alex" could exist in both databases with different login information
here you could simply add another field in the Login form (yes I've saw one application that does it) for example instead of Username and Password fields, ask for "Office, Username and Password", and the Office would be the name of the Customer database. Or you could even use only Username field and force users to enter something such as "alex#office" as Username, then you split that by "#" and you know to what office it belongs.
then simply use that information both on Login screen and on session to tell Yii what customer database to connect to
So as you see it could be done in different ways. Once you choose your way, you would need a implementation.
If you don't know how to do the implementation maybe I could provide more technical information related to Yii.
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.
I have started building a web app that has different user types - including Admins and Customers, and I want each account type to have its own users db table (sessions system etc), but with the same log in page.
The Admins don't sign up - they are issued an account, whereas the Customer sign up on a page dedicated to creating their account, so at this time and in the future, every user account type will have its own sign up page.
Yet all user account types ie Admins and Customers, should be able to sign in from the same page - without any differences - in the log in form ie no drop down to select user account type being logged into.
My goals are to have:
all user account types (3+) log into web app via same form,
no need for any visible user account type identifier eg in the formatting of username,
as secure as possible 'invisible' user account type identifier.
One solution I've thought of is: hashing the passwords differently per user account type, but with some constant in the hash that can be read on sign in to identify the user account type, that then points the log in process to the right db for that user, but that would require some kind of constant in the hashed output... and I'm stuck. Am I on the right track?
Does anyone know of a script/how-to/or article that covers such a process somewhere?
This must be used in a lot of current web apps.
Thanks
Where we've had to implement multiple account types (in big systems I should stress) we always settle on a general (Users) table to supplement the additional tables (Administrators, WebUsers, Suppliers etc)
The Users table would link to either an Administrator, WebUser etc and any 'generic' functionality (i.e. login, logs, recordlocks) would link back to the generic Users table.
Then from a Users record you can deduce what type of account it is and decide what they can/cannot do.
I should stress though that this is only because the structure of these tables is so different that they cannot all be stored in the same table. If there's only 1 column different, for instance, you don't need to do all this.