I know questions like this have been asked numerous times, but not quite this one. Forgive me if I overlooked an obvious duplicate.
In the core of many of my web applications is a self-written user/session management class that in its origins dates back to 2002.
I have decided that it is time for a fundamental re-write or, preferably, the introduction of a ready-made standard library.
My requirements for that library would be:
Object oriented, clean, excellent code
Full session management: Wrapper to session_start() and consorts
Would ideally provide various storage methods (PHP Standard /tmp, database based)
Would ideally be able to connect to different types of user data storage, but mySQL will do fine
Would ideally provide convenient functions for supporting OpenID, but that's a fancy thought, no requirement right now
Methods: Verify session, get user data, get session data, log in user, log out user
Settings: Session lifetime, password encryption
Must be Open Source
And if it's very generic, a user management API or a generic connector to the user management of the surrounding application would be nice:
Create/Update/delete user records
Fetch and modify data of currently logged in user
this is so basic, and so security relevant, that I would expect that there is a standard solution to this, however I don't know of any, and all the big CMSs and blogs seem to be rolling their own.
My two questions:
Do you know such a component as a generic, stand-alone library?
Could somebody with deep knowledge in Zend Framework tell me whether it is possible to use Zend_auth and/or Zend_session standalone, at the core of a big application that has otherwise nothing to do with ZF, without running in to trouble?
May I suggest the authentication library that I have written? It is a generic library (not written for or part of a framework): http://ulogin.sourceforge.net
Could somebody with deep knowledge in Zend Framework tell me whether it is possible to use Zend_auth and/or Zend_session standalone, at the core of a big application that has otherwise nothing to do with ZF, without running in to trouble?
I don't have deep knowledge of the Zend Framework, but I have used various components (e.g. Zend_Search) without creating a Zend_Application object or using the MVC framework and I am sure the rest of the library is also designed to be totally modular. Last time I dug though the Zend_Session code, I didn't find any includes outside Zend/Session/. A quick google seemed to confirm this for Zend_Auth, along with the Zend FAQ which states:
Is ZF a component library or a framework?
Simple answer: both. Zend Framework provides all the components required for most web applications in a single distribution. But Zend Framework components are also loosely coupled, making it easy to use just a few components in a web application- even alongside other frameworks! Using this use-at-will architecture, we are implementing features commonly found in more monolithic frameworks. In fact, we are currently working on a tooling component for the 1.8 release that will make it simpler to build applications using ZF components, yet will not sacrifice the use-at-will nature of existing ZF components. It's a testament to the use-at-will architecture of Zend Framework that the tooling component itself can be used standalone.
The only thing I had to do when not using Zend_Search with the MVC framework was add the directory where you installed the Zend Framework to the include path due to the includes in the Zend library. The documentation doesn't document the includes you need when not using the Zend Autoloader, but as everything uses the PEAR class naming scheme, it is easy to deduce from the class names you are using. (so the class Foo_Bar_File would require you to include Foo/Bar/File.php )
There are several OpenID libraries available.
http://wiki.openid.net/Libraries#php
For the rest you might as well roll your own, since figuring out someone else's library would probably be more trouble than it's worth.
My understanding is that there is no standard library because there is no standard definition of what a user is.
In some of my applications, users simply log in to do stuff. In others, users are part of a company and their permissions and data access are limited by the limits of that company and the subscription level paid for by the company. In other applications, some users are admins with access to everything, some users are admins with access to some data (row level), and other users are the clients of those admins, with access only to their own data. Some users are tied to firms/companies/customers, other users are not. Some users are just a username and password, others are a large object graph with clients, order histories, report preferences, comments, etc.
Maybe I'm wrong and there's some clean way of abstracting all of those requirements into a system that doesn't require five layers of subclassing and a thousand DB hits to log someone in. I haven't found it though.
Related
We have a pretty large Symfony 2 web application which has many different endpoints and features:
api for data from our legacy product
web components for use in our legacy product
api to our new iOS POS
api to loyalty end-user portal
web interface for loyalty end-user portal
web interface for (seperate) invoice end-user portal
big admin area with configuration for all of the above
The database layer (in Doctrine) on this is tightly coupled. Transactions from both the POS and our legacy product are used in the loyalty end-user portals and invoices are based on the same transactions. Obviously there's also many entities that are solely for specific parts of the application.
We originally decided on the single app+bundle approach for ease of programming, which has served us well in developing the whole platform. Unfortunately the main drawbacks are:
very bad performance (although things like further caching, minimizing assets etc can help, we think that having such a bloated bundle that needs to be able to handle everything and also included different 3rd-party libraries only used in specific parts of the application is slowing everything down.)
we use continuous integration and generating new builds and running all the functional tests is taking 20+ minutes.. and we still have many classes lacking (proper) tests.
when we change part of the application, another part breaks easily. Although more and more decoupling and functional tests help with that, it's still far from ideal.
I've done some research to splitting a Symfony project into multiple projects (each with it's own github) and using SOA to connect them. My personal experience so far with SOA is that it makes things very hard to test fully and adds lots of overhead when migrating from standard Symfony 2 forms (which I totally love).
I was also thinking on another solution by creating a shared bundle with the shared entities and repositories. This would make it much easier to test code and share common services (managers), although I've also heard argumentation against big managers. The big downside to this is that we cannot simply use doctrine:schema:update then, because sharing the database and updating the database on a project with a lower version of the shared bundle, will remove fields.. causing loss of data. Also on this approach I have been unable to find any examples or use-cases.. which leads me to wonder if it wouldn't have many more downsides.
So my question is: what are common approaches and solutions for splitting a big project like this? And: are there reasons that maybe it should not be split at all?
Although I'm answering your question, It's kinda hard to come with a magical solution for your problems. This is not an attempt to solve all of your problems, nor impose you of following it. This is not the only possible solution, actually this might not even solve your problems. That said, let's begin.
I'd split the project in 4 layers:
Presentation Layer: Desktop aplications, Web interfaces (no matter if
is php, C#, if it uses Symphony or any other framework and third
library components), Mobile Apps, everything end users can see and
interact with (also known as GUI). These guys only communicate with
Application/Service to request something, like a list of available
products, update some data somewhere, send an e-mail for customers.
The key here is they really don't know how and where is
Appication/Service layer going to do the requested actions.
Application/Service Layer: I'd treat this as controllers which can receive requests from the Presentation Layer, and external webservices as well. They look like APIs, and will decide if they have to access/manipulate data through a Repository, or send e-mails using some SMPT service. They just makes the communication between GUI or external webservices which might consume your APIs and Domain/Infra layers. Yet they don't actually know what SMPT service they are using, or where data is going to be stored and how (in a MySql through Doctrine? in Sql Server through Entity Framework? in a NoSql database? txt files?). Application layers usually have their own Models (also known as ViewModels), which are exposed to the world and returned to the requester (GUI or external Webservice), representing part of the domain models. This mapping (convert Domain classes to Application classes) can be done with patterns like Facade and Adapters (also called the Anti-corruption layer), and there are plenty of packages to resolve this (for C#, there is Automapper, for PHP there might exist something either). Why should you need this? To avoid exposing your full domain to the world. Suppose you have Invoice and Loyalty end-users, but you wanna treat them as one unique domain class "User" with their corresponding properties together. You could create a LoyaltyUser and an InvoiceUser classes in your application, each one containing only the necessary properties for that purpose, then use this Mapping technique to map the domain User class to each one of them. Therefore, the application layer usually contains authentication and authorization rules, so only the Loyalty end-user would have permission to access controller's actions which would deal with the LoyaltyUser model. Inside a single action in a controller, you shouldn't take different paths/ways depending on the requester (for mobile, do this, for website, do that). Instead, you might have different actions for each one, and tue Presentation layer knows what they want to request.
Domain Layer: This is your core, containing all business logic. This is what provide value to your business. Domain layer container
models/classes representing real entities from your world, interfaces
for services and repositories. Domain must be the most clean and
natural possible. They can't know what application is asking
something, nor how type of infra is being used. They just do business
logic. The Domain layer don't know if your are using Doctrine or Laravel as an ORM, nor if the application is a php website done with Symphony, or an Android Native App.
Infra Layer: Here you implement things like database, SMPT service, Logging, and other things your application might need.
Doctrine would reside here. Therefore, you would create Repository
classes implementing the repository interfaces of your domain. The
Repository implementation uses Doctrine to do stuff. These
implementations are providen to Application Layer (normally via
Dependency Injection). This means the Application Layer shouldn't
know if is Doctrine or Laravel, that's why the Application uses the
Repository (so logic to access database are encapsulated).
Your web interfaces would reside in Presentation. If the framework you use in your web have to use MVC and therefore have controllers, these controllers should dispatch to the Application Layer (I know it sounds redundant). Your APIs would reside in Application Layer.
This is very decoupled, if you need to change from Doctrine to Laravel, your don't need to change your Domain nor your Apps. If your need to change from Symphony to anything else, or even change your website from PHP to ASP or Java, your domain don't have to be changed.
Adding more layers, mapping objects, using DI shouldn't make requests slower, considering the hardware's price and capacity nowadays, the difference in time is almost imperceptible. You should put efforts attempting to improve your domain, which brings value for the business. Separating layers improve decoupling, chances of changing part of application breaking other parts, increase flexibility of scaling your app, and makes testing easier.
Rein, what was the solution you've finally ended up with? Have you actually split your project?
There is really a lack of information in this area, I just found one reasonable article https://ig.nore.me/presentations/2015/04/splitting-a-symfony-project-into-separate-tiers/
We have a project to build a web application that has many features like: google maps integration, item review and rating (something like eBay rating), chatting among users, content search based on content calculated value, integration with Facebook (for login, liking the content, fetch user's friends...etc),batch and real-time notification through SMS and email and many others.
We have two candidates for this zend and drupal, I tried to search a detailed
comparison between them without luck; only found high level stuffs.
Our criteria is to use a product which will not require lots of custom development and satisfies most of out needs out of the box, and it should be reliable and easy to maintain and extend in the future.
I would really appreciate if someone can shed some light on zend vs drupal comparison and point me to any useful recent analysis already done in this.
What are the real strengths of zend ?
Thanks in advance and best regards
Drupal is easier to have a project up and running with, it is a fully working web application out of the box. The flexibility of Drupal is pretty good, but be aware that using such a "pre-built application" type of framework tends to make the hard things easy to do, and the easy things hard to do.
Zend Framework, on the other hand offers much more flexibility, but at the cost of having to write things up from scratch yourself.
Actually, you are to choose from two different solutions. They are both used for building sites, but on a different level.
Base on the following:
Our criteria is to use a product which
will not require lots of custom
development and satisfies most of out
needs out of the box, and it should be
reliable and easy to maintain and
extend in the future.
I think you should choose Drupal. This is why:
Zend Framework is PHP framework, which enables you to build applications almost from scratch - you need to put some effort to reach the phase when you are able to actually use the application,
Drupal is Content Management Framework, that helps you build CMS system on the basis of your modules - only thing you need to start using base features is to install Drupal,
both Zend Framework and Drupal are extensible, but Zend Framework is much more extensible. Drupal has some architecture that should be followed and you can not do much about it (unless you really have time and resources to change it significantly and then be your own support, updating the core), but since you need "just extensibility" (not some major one), Drupal still meets your needs,
there are plenty of modules allowing you to add needed features to your application on both Zend Framework and Drupal, but in Drupal it is just as simple as copying the files and configuring it through the interface - there is usually nothing that has to be performed by developers,
You have to be aware also, that because of some architectural restrictions you should first analyze, whether Drupal is really suitable for your solutions. If you think the traffic will be heavy and you need different base concepts (user management, content management?), you probably should think about choosing more resource-consuming solution (which is Zend Framework).
Zend is an application framework while Drupal is more of a content management system (with some framework characteristics). That makes it difficult to compare them beyond those definitions.
Our criteria is to use a product which
will not require lots of custom
development and satisfies most of out
needs out of the box, and it should be
reliable and easy to maintain and
extend in the future.
There's no magic bullet for that but most of your criteria (pre-built modules) puts you firmly in the Drupal camp. It employ modules that you can plugin and config.
Drupal offers both the functionality of a framework (through modules and its API), and Drupal offers ready-made functionality. The trick is knowing Drupal very well.
Pre-made functionality in Drupal can be overridden through hooks, or you can find workarounds that DO NOT require modifying other modules, but sometimes this requires a lot of experience with the inner-workings of Drupal, for maximum control.
One major hurdle is deciding when to write in-house modules, or turn on modules provided in core or contrib. The problem (for me) is resisting the siren's call to use every module that Drupal provides either in core or in contrib.
Another technique is to turn on a module, and use the functions and data that the module provides, and create your own functionality on top of (or replacing) the functionality provided by the core or contrib modules.
With Zend, well they offer a very good set of classes but every page including admin pages, and features like caching, and routing will need to be built from scratch. In some ways this can be a good thing if it can get you away from the siren's call of wanting to use ready-made Drupal modules.
On the other hand, you own everything you have to make from scratch. With a community like Drupal, you can be part of a community that shares in development efforts.
I am currently exploring Zend_Auth, part of Zend Framework, but am dissapointed with the lack of more advanced features such as nonces, authentication tokens, lock-out, etc. In one of my recent projects, I implemented an authentication and ACL (Access Control List) scheme that has the following features:
Salted hashes
Automatic IP address lockout
Nonces (several types)
Authentication tokens (which persist for the entire session)
It would be great if I could abstract this functionality and make a reusable authentication class, but I was curious about whether a feature-rich authentication module already existed, so I could save myself the work. If not, I will most definitely do that.
I suppose my questions is this: What (database-based) authentication module/scheme are you currently using, and are you happy with its features? Specifically, is anyone using one that supports the features I listed above?
I look forward to your responses.
Funny thing, I was going to answer "Zend Framework!" when I saw this question. I guess that you are already using that.
I've done a lot of what you are doing using ZF as well. True that it is not all made for you, but the parts are there. Honestly, if it was already put together, it would not be flexible and not apply to many use cases. I'd rather make it suit the app I'm building, rather than build my app around it. You can make your code into library and include that with your other ZF apps.
I'd be interested in other options as well though.
Duplicate of
What is a PHP Framework?
and many more
So far, I've been using PHP for small tweaks, mostly with WordPress. What are PHP frameworks? Why do I need them? WHEN do I need them?
Any insight will be helpful. Thanks.
Frameworks are organized groups of code or libraries, built on top of a language to either
Make Common Tasks Easy/Simple
Create a Consistent Way to Develop Applications
Some frameworks are very restrictive (as in it's not easy to do things, unless you do them the 'framework' way), others are looser. I've found Zend's Framework to be a good mix of both, making easy to use single components (for example, you can drop the 'Feed' library into your existing application without needing to rewrite the application the Zend way), or you can use the Zend MVC and Application libraries to for an entire application.
I'd stay away from frameworks that are 'all or nothing'.
From Zend's Framework (restating the above, perhaps more completely):
Zend Framework is an open source framework for developing web applications and services with PHP 5. Zend Framework is implemented using 100% object-oriented code. The component structure of Zend Framework is somewhat unique; each component is designed with few dependencies on other components. This loosely coupled architecture allows developers to use components individually. We often call this a "use-at-will" design.
While they can be used separately, Zend Framework components in the standard library form a powerful and extensible web application framework when combined. Zend Framework offers a robust, high performance MVC implementation, a database abstraction that is simple to use, and a forms component that implements HTML form rendering, validation, and filtering so that developers can consolidate all of these operations using one easy-to-use, object oriented interface. Other components, such as Zend_Auth and Zend_Acl, provide user authentication and authorization against all common credential stores. Still others implement client libraries to simply access to the most popular web services available. Whatever your application needs are, you're likely to find a Zend Framework component that can be used to dramatically reduce development time with a thoroughly tested foundation.
A framework tries to provide all the things that are common to every (or most) projects - html rendering, database access, and so on - in a way that's simple and easy to use.
You would use one to speed development, because you can skip all that stuff, and focus on what's unique to your project. Depending on the one you use, it can also add some security features by automatically escaping data on the way to the database, or to the screen.
I use them in any situation where I don't need something so custom that it's more work to bend the framework to my needs than to create the whole thing from scratch. That's pretty rare.
Is there any open-source, PHP based, role-based access control system that can be used for CodeIgniter?
Maybe I'm misunderstanding the question, but isn't the whole point of Role-Based Access Control (RBAC) to avoid Access Control Lists (ACLs)?
RBAC differs from access control lists (ACLs) (...) in that it assigns permissions to specific operations with meaning in the organization, rather than to low-level data objects. For example, an access control list could be used to grant or deny write access to a particular system file, but it would not say in what ways that file could be changed. In an RBAC-based system, an operation might be to create a 'credit account' transaction in a financial application (...). The assignment of permission to perform a particular operation is meaningful because the operations are fine-grained and themselves have meaning within the application.
(Quote: Wikipedia)
I don't know the specifics on Zend_ACL or the other implementations mentioned, but if they are ACL-based, I would not recommend using them for role-based authorization.
Brandon Savage gave a presentation on his PHP package "ApplicationACL" that may or may not accomplish role-based access. PHPGACL might work as well, but I can't tell you for sure.
What I can tell you, however, is the Zend_ACL component of the Zend Framework will do role-based setups (however you'll have to subclass to check multiple roles at once). Granted the pain of this is you'll have to pull out Zend_ACL, I do not believe it has any external dependencies, from the monolithic download (or SVN checkout).
The nice thing about Zend_ACL is though its storage agnostic. You can either rebuild it every time or it's designed to be serialized (I use a combination of both, serialize for the cache and rebuild from the DB).
I created an Open Source project called PHP-Bouncer which may be of interest to you. It's still fairly young, but works well and is easy to configure. I ended up developing it because none of the existing solutions seemed to meet my needs. I hope this helps!
phpgacl http://phpgacl.sourceforge.net/ is a generic acl based access control framework
while I don't know about any CI specific implementation, i know that you only need the main class file to make phpgacl work. So i belive that integration with CI won't be any problem. (I've work passingly with CI)
Here are two RBAC libraries for PHP I found:
https://github.com/leighmacdonald/php_rbac
https://github.com/brandonlamb/php-rbac
I actually used the first one in PolyAuth: https://github.com/Polycademy/PolyAuth/
It's a full featured auth library that includes NIST level 1 RBAC. And yes, RBAC is not the same as an ACL. I use Codeigniter as well, all you have to do is use the PDO driver and pass in the connection id. See this tutorial for how to do that: http://codebyjeff.com/blog/2013/03/codeigniter-with-pdo
Found out about Khaos ACL which is a CI library... I'm also checking out phpgacl and how to use it for CI... Have'nt checked Zend ACL yet. But maybe it can be "ported" to CI
Try DX_Auth plugin for CodeIgniter. I am working on a similar (rather, superset) of the functions that DX_Auth have. My set of CI addon's include display of menus (that can be controlled via CSS), Role-bases access controll before controller is invoked and other features. I hope to publish it soon. Will give project URL when I do so
RBAC != ACL - Roland has the only correct answer for this question.
BTW of course it is an essential part of a framework to implement any kind of permission system - at least there is no point in using a framework, if it does not give you a well engeneered RBAC system - it might be better using a simple template system with any ORM layer then.
It is a common antipattern in the php world, that frameworks like Ruby or Django are "cloned" only as a subset of what these modern frameworks deliver - as a typical syndrome yuo see a lack of good ACL or RBAC integration into these frameworks - what essentially is a joke.
There is currently only the Yii PHP Framework that comes with a decent RBAC implementation.
I know the trail is cold, but a new project has popped up :
PHP-RBAC is a PHP Hierarchical NIST Level 2 Standard Role Based Access Control and is pretty mature. It is also an OWASP project.
I hope you enjoy it at http://phprbac.net
http://www.jframework.info (deadlink)
jFramework has a standard NIST level 2 RBAC with enhancements which is said to be the fastest available (includes benchmarks) it can operate on a single SQLite database file and is tested thoroughly, works like a glove.
Has a dependency on jFramework DBAL but you can simple replace DBAL SQL Queries in the code with your desired DBAL and of course you can use jFramework in a SOP manner.
Ion Auth Library uses users and groups - https://github.com/benedmunds/CodeIgniter-Ion-Auth
but there are no working RBAC system to use them and manage. But you can white your functions.