I have a Assignment to do. my DB has two tables, one for Tutor another one for users. users table is used to login to the system as student. and same goes for Tutor table. up to now students can login. but can't login Tutor.
When I'm entering Tutor login details it goes to users login. this Assignment is kind of Student feedback portal. using Yii2.
Can i do something by using 'switchIdentity()' or loginByCookie()?
Related
I want to implement Social login in my Django project. When I searched about it, I found social login for only one user. But I want to implement it for different type of users as I mentioned in the title. Can anyone suggest a solution to implement this in my project.
You can allow auto-registration to everybody. But, to be registered on your app doesn't mean user can do anything in app. Only users on group candidate , employer or customer are allowed to see data or perform operations in app.
Then, you can create views on your app to put users on group. For example, a user of the grup employer can assign users to group customer.
Get the groups the current user belongs to.
Briefly about the project:
i am working on a VSTO project for Excel using vb.NET
buttons are provided in Excel for the users.
these are to be assigned on the basis of the AD group
I want to read out the AD groups to which the user currently logged on to the computer belongs.
Are the groups retrieved from the AD cached on the PC.
If yes, it would be very easy to read them, but so far I could not find anything.
If not, how can I check which groups the user belongs to without having to fiddle with passwords?
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
I need to implement a login system in MERN stack in which there will be three types of logins.
1. Admin login
2. Student Login
3. Faculty Login
The admin login will have a pre defined username and password (say admin & admin#123 resp.) which can be changed if needed.The faculty and student will only be able to login if the admin adds new student or faculty from his dashboard.The student and faculty username will be the registration number from college and password will be the date of birth.
All the tutorials that i came across are on registration and authentication & since registration is not a part of this project, I'd like to know basically how i should go about with this feature.
I am using mongodb as the database.
You have multiple things going on here:
authentication: accepting and checking a username and password
authorization: once a user has authenticated herself, assigning her the appropriate privilege level (admin, faculty, student in your case).
registration: in your system only the admin can register new users. This is different from some systems, which permit self-registration. Yours does not, according to your requirements.
(Important security tip it's a seriously bad idea to use date of birth for a password. Why? if a cybercreep breaks into your database, he will have a list of names and dates-of-birth. Those are useful for stealing your users' identities. They are also considered personally identifiable information and so they're covered by by GDPR and the California Consumer Privacy Act. But you didn't ask about that.... )
Let's take your requirements one-by-one.
1-authentication. This is a simple username/password scheme. Use the passport module for that, with its local strategy.
2- Authorization. When you look up the user also look up her privilege level (again admin or faculty or student). Passport feeds your user a session cookie so they stay logged in.
Before you display any page or accept any API request or form-post from a user, check the authorization level. If the user is not permitted to use the particular feature, send back a 403 error message rather than showing the page or accepting the form.
3- Registration. You need a form for creating / replacing / updating / deleting users (called a CRUD form). This form must be accessible only to your admin.
By the way, all this happens on your node / express server. Your react client must simply pass along the passport-generated session cookie with every request, so the server can look up the user to retrieve the authorization.
Thinking about your requirements in this structured fashion should help you apply the stuff you learn from various online tutorials.
I have read about creating and responsibilities of aggregates and I have doubts how to correctly implement them. Assume that we have context within there are 2 entities. One is a Company and the second one is a User. Business rules are in the Company entity that means this should become aggregate root. To the Company we can assign ony 3 users and we can not assign User when Comapny has status "blocked". User has also possibility to login using emial and password. With that in mind every action on User entity should bo invoked thru the Aggregate root and User should not have it's own Repository. How to make login action on User when we can not do it directly without Company root? We can not call User out of the aggregate. How to find User with provided email and password? Fetching all Aggregates and iterating over their Users is inefficient and I think it's not a good idea.
Thank you for help.
I think that user should belong to another BC (that manages authentication and authorization). In your Company BC, you have to get the user from the authentication and authorization BC. You have to integrate both BCs with a context mapping pattern, where authentication and authorization BC is upstream, and Company BC is downstream.
Authentication usually isn't part of a domain (in 99% of all use cases), just part of the infrastructure.
As such Users shouldn't ever appear within a bounded context. In the real business world, there are no users neither, only People, Persons, Employees, Managers or Contacts etc.
So for logging concerns you have our users with username + password which serve as authentication. These users have an id (numerical, string or guid).
Your Employee or Persons entity/aggregate (or what ever you named it depends on your domain, the exact term depends from company to company - the ubiquitous language) then only contains the data which belongs to the person (but not identificaton related information).
You can then connect employees to users (either by having the employee id be the id of the users used for login, an extra field or via a 1:1 or 1:n lookup table.
This way you can easily delete a user (the login) without deleting the Employee entity, because in real world scenarios you can't easily just delete business data (i.e. imagine deleting a user removes the recipient on every invoice or CRM data, no one would ever know this person worked there in the past).