Experts,
what's the recommended way to pass the user id (system internal id of the user used to query for the user info) between controllers in a codeigniter app?
I'm considering the following options:
1. Use the CI session id to query the database for the user id in every controller. That way I don't have to place the user id in the session which is a security concern. But this option means an extra db query in every controller
2. Store the user id directly in the session so I have it readily available to query for user info.
What do you think?
From my understanding of MVC you're not normally supposed to talk directly between two controllers. However in this case I would use the session. As far as security goes there are plenty of extensions to codeigniter dealing with authentication such as TankAuth and WolfAuth including many others that you might look into if that is your concern. In this case however I'd say using the session to store a user id is perfectly fine as long as you're not storing sensitive data along with it.
You can read up on CodeIgniter sessions here: http://ellislab.com/codeigniter/user_guide/libraries/sessions.html
There is a great authentication library Ion Auth. Check it out
http://benedmunds.com/ion_auth/
Related
I plan to develop a system that has three user types (admin, business, personal). I want to have each user types information stored in a separate table for easy access and to reduce the number of blank fields (if they were all in one table).
Having looked at multiple Multi-auth packages available for Laravel, they all appear to be insisting on an approach with URLs like the following:
/admin/login
/business/login
/personal/login
Ideally, I would like to take an approach where the standard Laravel Auth /login can be used meaning that all users log in from the same page.
My knowledge of Laravel is limited so all and any help is appreciated.
The usual approach is to have one users table which has the ID/email/username (as primary key), login credentials and user types for all the users which will be logging into the system. The information however can be stored in separate tables for each type, referencing the foreign key.
After authenticating the user, then you can decide what to do with the user based on the user type.
If you store login credentials in multiple tables, that's data redundancy. Unless you want the same email/username to have more than one user type, but then during login, the user has to decide which user type they want to log into (maybe by selecting a dropdown option).
Update: about user roles
If you need to simply redirect users after logging in, use $redirectTo. Or if you need to decide what to do with the users depending on the roles after logging, you can make use of authenticated() method (add this method if it's not already there, it will overwrite the AuthenticatesUsers trait) inside your AuthController/LoginController.
Throughout your application, I'd suggest assigning middleware to route groups to restrict routes based on user roles. And yes, in your views and controllers you can use something like if(Auth::user()->hasRole('business')) when needed, but first you'll need to create the hasRole() method in your User model. If you feel it's getting complicated, you may try packages like laravel-permission and Entrust. I haven't tried them though :)
In my application I need to register users. The users can be any of three: admin, client and general. They have different attributes (Admin may have only name, client may have company address and so on). The default MVC membership scheme is okay but how can it be extended to register more information during registration time? Or should I use custom membership?
I need to have a record of clients and general users with clientID or generalID.
The default MVC membership scheme is okay but how can it be extended
to register more information during registration time? Or should I use
custom membership?
I think too many people, yourself included, are expecting to get too much from the default ASP.NET Membership Provider. It was never designed to handle application-specific things, like what company your customer works for, your admin's name, and so on. It's main purpose is storing passwords for authentication.
Sure, the password needs to be linked to a username, so that there can be a 2-key authentication pair. Sometimes you also need the user's email address, when it is different from their username, in order to contact the user regarding their password. But don't store anything else about your users in the membership store. Store it in your application database.
In order to join data between your application and the membership provider, use the membership provider's UserName or ProviderKey as a column in one of your database tables. You end up with 2 entities which are not explicitly related. You can even have your SqlMembershipProvider implemented in a separate database from your application database. Even if they are in the same database, avoid having a foreign key between any of the provider tables and your application tables. This muddies the waters between what you own, and what you "outsource" to the membership provider.
You end up with 2 physically isolated representations of your user. One is the MembershipProvider, which contains a password for your user. The other is your application, which contains other business-specific details. The two are only logically associated within your application. After you authenticate a user with the membership API, their UserName and/pr ProviderKey become available to your application. You can then use that piece of data to query your app database and get the additional details. This is where you might put something like the clientID or generalID you mentioned.
If you look at the System.Web.Security.Member* API, this should make things clearer. It does one thing really well -- associating your users with passwords and other information related to password resetting (like the email address, question and answer, etc). So outsource just the password provider, and rely on your application to do the important stuff.
You could customise the default profile provider or create your own... Follow this reference
http://msdn.microsoft.com/en-us/library/8zs47k7y
You can add new properties to the profile for anything in the web.config too
I highly suggest creating your own membership roles. It's dead simple and nothing can beat the flexibility of having your own implementation.
Here's a video I made a while back showing you step by step how to achieve this:
http://www.youtube.com/watch?v=BsxUsyMSGeA
The gist of it is, you create your own AuthorizeAttribute and create your own roles; protecting each controller or even individual Action methods along the way.
The one drawback of this approach is that you can determine what Role a user has in your system, but not what a Role can do in your system. Does that make sense?
There are other choices if you need to edit what a role can do at runtime.
I just started an MVC 3 project using Forms Authentication. I have a web project (mvc project), and a data project. The data project handles all database interactions.
I need to store the current user id in my database on every insert and update.
Here's what I am doing right now. I feel like this has to be a common scenario. Can anyone shed some light on a better way to do this?
On LogIn or Register, I grab my current user record (by username) from the database and store the user id in session.
When saving a record within my data project, I refer to the httpcontext (if it exists) and use the user id that is stored in session.
This works for all but one scenario. It fails when a user has a valid cookie saved, and so they are allowed to bypass the login/register action. When this happens, obviuosly, my session variable for userId is null. My next step would be to create a base controller and imlement OnAuthorizeStarting to check if my Session variable is null or not. This feels kludgy, and I'm hoping there is a better way.
I do not want to have to pass the user Id to the data project as a parameter on every Save call.
Anyone have some brilliance? thanks.
The UserID is available via membership. So, something like this:
Membership.GetUser(HttpContext.User.Current.UserName).ProviderUserKey
The IPrincipal (HttpContext.user.Current) is created when the user is authenticated against the forms authentication cookie. You just pull up the user id from the Membership whenever you need it.
If you don't like accessing Membership every time then you can always create a static helper class that wraps your UserID session call. If it's null, it goes out to the membership provider, gets it, then stores it in the session.. on later accesses it just retrieves the session variable.
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.
I am building an ASP.NET MVC3 app using Forms Authentication and I'd like to log out all existing sessions for a user when that user logs in. I'm trying to prevent multiple people at different workstations from logging in and working under the same account.
Is there a standard way of handling this? Logging out the existing session is easy, but I haven't come across a way to check for other sessions by the same account and log them out.
I have a few ideas on how to hack this, but I'm curious if there's an established method for this using IIS or the FormsAuthentication API.
Because of the statelessness of the web, you can't "log out" a session until they make their next request (for instance, session might be maintained in a cookie, which can't be written on the client outside of the context of a request-response interaction).
There is still a solution, which assumes you are using session state, and preferably you have a common base controller for all of your controllers requiring "Authentication".
Upon successful login, generate a token (a guid perhaps) and store that with the session. Also write this to a application-wide store (database or application context for instance) keyed by the userid.
In the Base Controller (or otherwise you'd have to create an action filter) check the token in session against the token registered for the userid in the application-wide store. If they don't match, log out the user using the standard SignOut() call.
You could use the Membership.IsOnline property which is based on LastActivityDate:
A user is considered online if the
current date and time minus the
UserIsOnlineTimeWindow property value
is earlier than the LastActivityDate
for the user.