I am developing the ability for administrators to log in and I'm to the point of creating the admin log-in page, but I'm somewhat torn as to where the best place to put it.
For details, this is part of an MVC framework, and the administration portion is in it's own folder - /admin; so administration is completely separate from the public portion of the site.
I would like to place the actual log-in page in its own php file for security by separating it from the rest of the site. That way if they bust one, they don't bust all. However, then you get to the point of processing the log-in request - should it be in the same PHP file as the log-in, or should it reside in another file, or should all of this just be part of the framework?
Any suggestions would be much appreciated.
EDIT: just for some clarification, this is my first time creating any sort of user system, so please bear with me :) (Any good tutorial/example links are greatly appreciated too).The admin portion of the site is in it's own folder but uses the same base files, classes, etc as the front end - the files are only overwritten in the admin portion as needed. Also, an 'admin' is just a certain user type - roles and permissions have already been figured out.
I'm just having a hard time starting - particularly where to implement/put the login form. I thought it would be best for security to have a physically separate file for login, but I see that might not be the case.
I agree with the rest of the posts, Admin should be in the same work-flow. Here is a good example to reference.
Using the same login system for both admin and users will enable you to simplify your application. First off, you'll only need to create one login form. Secondly, if the admin section is part of the same codebase, you'll gain a huge benefit from being able to access all of the classes used throughout the site. If you used an MVC architecture, you'll probably want to use the same models in the admin as you do on the site. Even if you didn't, there is probably still a lot of code you can reuse for the admin section (base classes, database abstraction layer, shared settings/configuration, etc).
IMHO, Admin should login through the same form as regular user, but permissions should allow him to view additional content.
You can place admin forms in any folder, and then allow admin to access it.
I think the admin user should just be another class of user (or be an option for a normal user). Take note that there's slightly more chance of granting access to a normal user by mistake with this approach.
Related
We have eZPublish 5. The authentication is handled by User kernel module kernel/user/login.php. This PHP script is called when trying to access a siteaccess which requires authentication.
Example scenario:
When trying to access http://example.com/marketing
it redirects me (when not logged in) to http://example.com/marketing/user/login
Which is expected behaviour.
What I would like to achieve is to rewrite the kernel/user/login.php file and preferably keep the url the same (this is not mandatory).
I need to do this because I need to integrate Duo Security Multifactor Authentication, so I need to handle the logging in in a custom way.
So on the first page I need to display the login form, then when it is submitted I need to verify if credentials are correct (but not log in the user at this phase) then I need to return another view where an iframe is present for the second authentication, and when the second authentication is successful only after that I can login the user and redirect him/her to the desired page.
Is there any way how to do this? I tried to create an extension with a module user and view login.php but it doesn't worked - the User kernel login.php is executed always when http://example.com/marketing/user/login is hit.
I am trying to do this for several days now but no luck and I'm out of ideas.
Thanks in advance for any help.
Welcome to the eZ Community!
What you want / need is both possible and quite simple to implement :)
First based on your description I recommend the following:
https://github.com/brookinsconsulting/bckernelmoduleoverride
Note: We forgot to package and release this extension some time ago but have been using it as part of our open source ezpedia.org code base. We thank you for reminding us and prompting us to package the code for individual usage.
Concerning double authentication we did something similar but actually quite different with this solution:
https://github.com/brookinsconsulting/bcconfirmpassword
Now code sharing aside. You may want to first study the login handler system which provides for many forms of custom user authentication system. https://en.ezpedia.org/en/ez/login_handler
Yet from your description and some intuition on our part it truly sounds like without more information that you very well do need to both override the default user/login module view (what we call a kernel module view copy override; copy the default module and customize the code within an extension module). We have done this -a lot- for special customer use cases and it's not very hard.
Most of the time the hard part is getting all the module and module view identifiers to not conflict once within an module extension and we think that will be less of a problem for you if you simply use / leverage the bckernelmoduleoverride extension which provides for using default kernel modules and module views customized within a module view extension.
Please feel free to ask further questions or share more information about your custom authentication system your trying to integrate. Frames in this day and age sounds like a painful system to be required to implement for a secondary authentication system.
We hope this helps!
Note: This thread is cross posted from: http://share.ez.no/forums/ez-publish-5-platform/ezpublish-5-custom-user-authentication-multifactor
The title says most of it, but is there a way to link from a page in the front end to a component in the backend WITHOUT asking the user to login again. Some thoughts come to mind, Sessions tables, and cookies, but I'm just not sure how to go about doing it. Any suggestions?
Joomla! runs as two separate applications, one for the front-end and one for the back-end.
To do what you're suggesting is problematic:
Any system you implement to get this working could compromise site security.
You would have to find/build a mechanism that logs the user into both the front-end and back at the same time.
As both back-end & front-end use different tokens and sessions you would also have to keep both of those alive as well.
As part of this process your software should probably limit back-end auto logins to those with the right permissions as well.
I'm not aware of any extensions that do what you want but there are some that allow some backend functionality in the front-end - you can look in the "Site Access" section of the JED.
Why not just add a frontend view for the component you want to display? For example like this.
I am building a symfony based website, which has users and admins. Normally, I would let them use the same app, and display different pages for the admins by checking their permissions (I am using sfGuard plugin).
The Admins use the same modules as the other users, but the views are different. The admins can search for all user data and can see all the users at once. They can also edit anything.
But I am wondering if it would be better to use a backend app only for Admins? That's the way the jobeet tutorial does it. So the admins would go to this backend app instead of the other one that everyone else uses....
What would be the pros and cons of each approach?
Thanks.
If you're not using the backend admin generator, I'd keep everything to the frontend application, as I don't see major benefits for having a separate backend app in this case. You can separate the user experience for normal users and admins inside the frontend application just the same, all the way from their own login pages to "admin mode" template views etc. sfDoctrineGuard comes with groups and permissions so it's easy to set up. Plus you won't need to duplicate frontend app settings in the backend app just to make things work the same way.
This decision is a balancing act. The best answer depends on HOW DIFFERENT the functionality and permissions are between the two types of users. If your site is very complex, it will become easier to write, maintain, and test the code in separate apps. If there are just a few little differences, you will prefer the simplicity of only one app to maintain.
For example in our system, we have our own system admins which are allowed to do and see far more than the customer "admins". The customer users have different tiers of permissions with their admin level being the highest. However, even those customers can not access any of our backend, which has numerous modules they can't see, and completely different sets of forms. We even run these apps on different virtual hostnames even though it's within the same Symfony project.
Having separate apps like this allows you to more easily make sure the security is right by keeping customers completely out of the backend and all of its modules. We have some modules that are similar in backend and frontend, but the customer side has to have a lot more custom restrictions on which records & fields they can view/edit to keep them out of other customer's data.
If we tried to mix all those customer restrictions along with our super-privileged capabilities we'd have a nightmare of complex conditionals and queries and it would be far too easy to make mistakes and allow customers access they aren't supposed to have.
I am developing an application in cakephp, I have to provide a user page for each user in the site like www.example.com/username, username will changes for each user, when a visitor comes to this url he gets details of the user with that particular username, but in cake username tries to get the controller with that name, How can I done this ?
My first response would be to say "don't do that". What happens if you decide to add a promotions page at some point in the future but you've already got a user named "promotions" or you want to add a forum system but you've already got not-very-nice users named "forums" and "boards"?
Better to do something like www.example.com/users/username. (eg. www.example.com/users/ssokolow) That's how all the sane sites do it. In fact, on a related note, Mozilla just redesigned the addon collections system so that collection names are namespaced under the usernames to solve a similar issue.
Anyway, whatever you decide, instructions for customizing your URL mappings independently of your controller designs are in Section 3.4.5: Routes Configuration in the CakePHP 1.3 manual.
You'll want to set up the order of precedence so that CakePHP tries everything else first (like the login page and the submit handlers for forms accepting user data) and then tries your username mappings as the last thing before giving up and returning a 404.
You'll still have to manually maintain a list of usernames that are banned because their profile URLs would be overridden by site-global stuff (eg. login) and you'll still have to watch out for cases which malicious users might be able to exploit to trick other users into something, but it will work.
You can do it with routes as a fallthrough at the end of the routes file, but it's not advisable - ssokolow has explained why. I have used something very similar for a CMS, but for pages rather than users and uniqueness was maintained by the system.
If it's essential that the URL reads like www.example.com/username rather than www.example.com/users/username then I would look at doing it by apache rewriting the url. This will probably still give you problems if a username coincides with a pagename and may well be confusing for visitors not to mention search engines.
Keep it simple - don't give yourself a headache.
It's a nice feature for users to access their accounts in this way and, contrary to other answers, I don't think it's a headache or undesirable in any way.
The best way to achieve this is with routes, but not manually - database driven routes. Mark Story has a great article on the topic and I've used this approach with great ease and success on very large websites:
http://mark-story.com/posts/view/using-custom-route-classes-in-cakephp
The only change I make is that I maintain a table called "routes" and have a corresponding Route model. The routes table simply has id/name/value fields. The name is the nice URL (in your case "somegreatuser"), whilst the value is the system URL (e.g. users/view/123).
All you need to do is maintain a blacklist of reserved usernames which is easily done using validation in the Route model.
I am currently writing a CMS and remember someone (it might have been on here) criticise the existing CMS for not having a robust enough user permissions system. I've got a method planned out but it I feel it has fallen into the usual trap of being a bit too fine-grained which makes understanding and implementing it a horror for end users.
I think having a range of default user roles with permissions would be the answer to this, so I suppose my question is this:
What are the default roles you would like to see in a CMS and what sort of permissions would be associated with these?
Thanks in advance!
This is the "best practice" I have ended up with in most projects and am very happy with:
1. Roles
When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.
2. Rights
Rights is where things need to be easy to understand and implement.
I have made very good experiences working with, and checking against, very fine-grained rights on the code / API level:
see
view
edit
change name
rename
delete
move
change rights
etc.
but the user never sees those. For them, they are grouped into a very small number of "right groups":
Read Only
Edit
Administer = Move, rename....
The user never sees the "move" right, but only the "Administer" rights group.
That way, you retain the full power of fine-grained rights in your code for the future - you can, for example, easily accommodate for a rule like "interns must be able to edit pages, but not be able to change their titles, nor to delete them", adding a valuable asset to the CMS. For the end user, this functionality remains invisible, and the rights system easy to use.
I asked this question a little bit ago and got the following response.
admin //Manage everything
manager //Manage most aspects of the site
editor //Scheduling and managing content
author //Write important content
contributors //Authors with limited rights
moderator //Moderate user content
member //Special user access
subscriber //Paying Average Joe
user //Average Joe
Have you researched existing solutions like RBAC? Whilst such a system would most likely be complete overkill for the particular nut you're trying to crack it would at least help to boost confidence that you're on the right track.
That aside, the general roles I'd expect would be along the lines of:
Administator - Total control of the system, can view logs (as you should be logging all changes), etc. plus...
Publisher - Can put content live plus...
Author - Can create content
However, how these roles are applied across the system is where things get tricky, as a specific user would presumably have different rights to different content areas/modules.
For most applications, so I think it'll be true for CMSs as well, my customers usually prefer a rights-oriented approach. Here is how it goes :
You list the main actions. In your CMS that would be : Create and edit content; Delete content; Classify/categorize content; Validate content; Publish content; Manage users; Etc.
You define what actions are allowed or denied for each user
To make things a little better, you can create several roles (Editor; Administrator) to make typical users creation easier (by pre-filling the form when a role is chosen).
I have a custom CMS built on the Zend Framework that uses Zend's ACL to extends some basic roles (so you can deny resources specifically for additional users or allow others to access resources they normally couldn't). My basic roles go from CMS users all the way down to website "members" as follows (I just use one users table to store all my authentication).
Developer
Edit any content, edit layouts, settings, configuration. Use special tools that can call shell scripts and force cron jobs.
Admin
Edit any content, edit layouts, settings.
Author
Edit content.
Member
Can view the login screen, forgot password and bug report.
Now, Zend has a nice ACL implementation so you can easily extends your base ACL class and add new roles that extend from the basic roles. So I might make an "Admin" who has access to one of the Developer tools (e.g. purge or cache management) or lock an author to only be able to manage blogs (and not for example news).
I wouldn't necessarily dismiss the fine grained control system you have now. If you have one that is adaptable focus on hiding away the complexity by providing a simplified interface (eg use the facade pattern or the adapter pattern). The benefits are that you provide users with the simplified version (simple permissions like 'admin' can 'delete' a 'post') while still retaining the fine grained features should you need them later (eg more complicated permission handling is to allow to delete posts when the post is your own post in category X). Then you can provide an alternative to the simplified version for that need in some places.
Admin : The one with all the rights
Author : The one who has all rights to a specific content (like a blog author who owns the blog), also has the permissions to add/invite users to collaborate/view the content
Collaborator : The one who can edit/add content to which the author has given rights, cannot delete the content or invite/add more collaborators
Viewer : The one who can view the content if the author has invited to view
Editors : The one who can approve/edit all types of content
Having a fine grain control is not a bad idea if you expect advanced users/developers to use the CMS. But for novice CMS managers, the basic roles make the system much more usable.
Administrator - can create users + all below
Editor - can edit posts of others + all below
Author - can write posts, edit own posts
Creator - responsible for creating and editing content.
Editor - responsible for tuning the content message
and the style of delivery, including translation and
localization.
Publisher - responsible for releasing the content for
use.
Administrator - responsible for managing access
permissions to folders and files, usually accomplished
by assigning access rights to user groups or roles.
Consumer, viewer or guest- the person who reads or
otherwise takes in content after it is published or
shared.