CakeDC Blog

TIPS, INSIGHTS AND THE LATEST FROM THE EXPERTS BEHIND CAKEPHP

Launching your new site? Read this first!

As exciting as launching a brand new website is, there are a lot of expectations that can be built up around it. Here are some top tips to not fall into the easy traps of launching your website   Don’t be a perfectionist It can be easy for some people to take the perfectionist view point when launching a new site. Rather focus on launching your website to its best and get feedback from testing and website visitors.   Doing it all yourself With the launch of your new site, it's important to delegate - make sure you have a expert team behind you so that you can manage your business and end goals. CakeDC, the experts behind CakePHP, believe in this philosophy - we lead, so you can lead.   Create a launch plan, now! If you do not have a plan for your launch, then the time is now! With research and strategy building, your launch will have direction, while reaching the right audience. Write everything down and be sure to share it with your team.   Linking to all Social media platforms With social media becoming an important way to reach out and talk to potential clients, it is key to ensure that you link your social media accounts to your websites and visa versa.   Have you tested? Testing is another key part to the success of your new site’s launch. Be sure to not miss this step. Not sure how to properly test your site? Here’s a great checklist to check out. From how to test elements such as HTML, CSS, security and performance through to SEO and accessibility, this checklist will guide you along best practices when it comes to testing.   Relax and execute your plan Lasty, relax and execute your plan! The final step to your new site’s launch is rollout. Things should be set up and in place which allow you to roll out your launch with minimal hassle.   At CakeDC, our goal is to help you, as a business leader, develop, achieve and maintain your competitive leadership in your market. Contact us to find out more about how we can create your custom application today.

Do you ever code for free? Contributin...

If you have ever taken a moment to contribute to open source, then you would know that it can be quite rewarding. But perhaps you are involved in an open source community, but aren’t necessarily contributing - yet! Maybe you are too nervous to contribute or you make a list of excuses as to why you aren't able to commit the time.   If you aren’t contributing just yet, here are some great benefits to you to start today.   Meet others in the community who are interested in similar things The CakePHP Community is welcoming and warm - by getting involved in the forums, online chats or through other participation, you can get to know others with similar interests.   Finding mentors within the community Get to know the community by getting involved - is there someone in the community who you think does an amazing job doing what they do? Chat to them, learn from them. There are some incredible mentors in the open source world - and they are normally down to earth and approachable.   Grow your knowledge and skill set base By contributing to open source, it gives you the opportunity to practise your skills. Through community involvement, you will learn new ways of doing things or suggest ways to improve on how things are done.   Help others - sense of giving Find reward in helping others solve the problems that have been troubling them. Giving back to the community brings in many rewards and a sense of achievement can be gained by helping out.   And now you may be asking - but how do I start? Easy! Just go ahead and find some issues that you can help out with, or simply join the support forums around the community and answer some questions - people appreciate the help and you never know, you could find help by helping others!   At CakeDC, time is committed to open source contributions. From our open source plugins through to support on community platforms, CakeDC ensures that time is committed to ongoing community support.

Why free website builders are hinderin...

Perhaps you are budget conscious or you are not computer savvy, and website builders look appealing to you. When getting a website developed for your business, key questions to ask yourself include: can it be managed effectively; will you be able to drive your brand online; will it be safe and secure? While website builders may seem like a good option, it can cause your business harm. Here’s a look at some of the cons of website builders.   You do not own your website Should you choose to leave your website builder, the website you have designed and any elements remain the property of the builder. You will essentially need to start over. From your content through to your domain name, all of this may need to be given up (as you are not the owner).   Website URL is not fully customizable When making use of a website builder, you are limited to the options that are provided. Some website builders offer different tiers, depending on your monthly subscription fee, however, you may need or want to do something that is out of the standard template.   Use of templates and outdated coding practises The use of templates is standard when building a website using a website builder. However, the use of outdated, unresponsive and badly designed templates can seriously hamper your brand (and website’s) ability to speak to your potential clients. These templates can use clunky, old fashioned and simple design.   SEO can be problematic With only basic SEO tactics employed by website builders, caution needs to be taken! Lacking SEO functionality can hamper your website’s ability to be found by potential clients - not appearing in search results and a lack of visibility can be damaging to your business.   Options, such as 3rd party integrations, are not available If you are looking to integrate 3rd party options, then think again - with only a limited options available, the ones you may want could not be available. For some business owners, this realisation may come too late and only after the website has been established, leaving them caught in a bad situation.
  Customized website application solutions are the way to go if you want to properly represent your business online. From increased functionality options, to fully scalable solutions that will grow with you and your business. CakeDC, the experts behind CakePHP, can offer you solutions that will answer every problem you have previously encountered with cheaper and less secure development solutions.

Building an RBAC based application in ...

This is the second article about RBAC in CakePHP series (2/2). In our previous post we did a quick introduction to RBAC and how to setup CakeDC/Auth plugin in an example project, dealing with basic array based rules. Today we'll talk about how to debug rules, and provide complex Auth rules to check permissions. We'll also discuss how to encapsulate the rules logic into `Rules` classes, and how to deal with RBAC in big projects.  

Debugging rules

Notice when debug is enabled, a detailed trace of the matched rule allowing a given action is logged into debug.log For example: 2017-10-04 23:58:10 Debug: For {"prefix":null,"plugin":null,"extension":null,"controller":"Categories","action":"index","role":"admin"} --> Rule matched {"role":"*","controller":"*","action":["index","view"],"allowed":true} with result = 1 This log could save you some time while debugging why a specific action is granted.

Callbacks for complex authentication rules

Let's imagine a more complex rule, for example, we want to block access to the articles/add action if the user has more than 3 articles already created. In this case we are going to use a callback to define at runtime the result of the allowed key in the rule. [ 'role' => '*', 'controller' => 'Articles', 'action' => 'add', 'allowed' => function (array $user, $role, \Cake\Http\ServerRequest $request) { $userId = $user['id'] ?? null; if (!$userId) { return false; } $articlesCount = \Cake\ORM\TableRegistry::get('Articles')->findByUserId($userId)->count(); return $articlesCount <= 3; } ],

Rules example

As previously discussed, we have the ability to create complex logic to check if a given role is allowed to access an action, but we could also extend this concept to define permission rules that affect specific users. One common use case is allowing the owner of the resource access to a restricted set of actions, for example the author of a given article could have access to edit and delete the entry. This case was so common that we've included a predefined Rule class you can use after minimal configuration. The final rule would be like this one: [ 'role' => '*', 'controller' => 'Articles', 'action' => ['edit', 'delete'], 'allowed' => new \CakeDC\Auth\Rbac\Rules\Owner(), ], The Owner rule will use by default the user_id field in articles table to match the logged in user id. You can customize the columns, and how the article id is extracted. This covers most of the cases where you need to identify the owner of a given row to assign specific permissions.

Other considerations

Permissions and big projects

Having permission rules in a single file could be a solution for small projects, but when they grow, it's usually hard to manage them. How could we deal with the complexity?
  • Break permission file into additional configuration files
  • Per role, usually a good idea when you have a different set of permissions per role. You can use the Configure class to append the permissions, usually having a defaults file with common permissions would be a good idea, then you can read N files, one per role to apply the specific permissions per role.
  • Per feature/plugin, useful when you have a lot of actions, and a small set of roles, or when the roles are mostly the same regarding permissions, with a couple changes between them. In this case you will define the rules in N files, each one covering a subset of the actions in your application, for example invoices.php file would add the pemissions to the Invoices plugin. In the case you work with plugins, keep in mind you could write the permission rules inside each plugin and share/distribute the rules if you reuse the plugin in other apps (as long as the other apps will have similar roles).
  • QA and maintenance
  • It's always a good idea to think about the complexity of testing the application based on the existing roles. Automated integration testing helps a lot, but if you are planning to have some real humans doing click through, each role will multiply the time to pass a full regression test on the release. Key question here is "Do we really need this role?"
  • Having a clear and documented permissions matrix file, with roles vs actions and either "YES" | "NO" | "RuleName" in the cell value will help a lot to understand if the given role should be allowed to access to a given action. If it's a CSV file it could be actually used to create a unit test and check at least the static permission rules.
  • Debugging and tracing is also important, for that reason we've included a trace feature in CakeDC/Auth that logs to debug.log the rule matched to allow/deny a specific auth check.

About performance

Performance "could" become an issue in the case you have a huge amount of rules, and some of them would require database access to check if they are matching. As a general recommendation, remember the following tips:
  • Rules are matched top to bottom
  • Try to leave the permission rules reading the database to the end of the file
  • Cache the commonly used queries, possibly the same query will be used again soon
  • Note cache invalidation is always fun, and could lead to very complex scenarios, keep it simple
  • If you need too much context and database interaction for a given rule, maybe the check should be done elsewhere. You could give some flexibility and get some performance in return

Last words

We've collected some notes about the implementation of a RBAC based system in CakePHP using our CakeDC/Auth plugin. As stated before, there are many other ways, but this is ours, worked well on several projects and we thought it was a good idea to share it with other members of the CakePHP community to expose a possible solution for their next project Authorization flavor. Please let us know if you use it, we are always improving on them - And happy to get issues and pull requests for our open source plugins. As part of our open source work in CakeDC, we maintain many open source plugins as well as contribute to the CakePHP Community. Reference

Building an RBAC based application in ...

This is the first post of a small series covering how to setup, organize and implement an RBAC based authorization system in CakePHP using the CakeDC/Auth Plugin. We'll cover the basic concepts, setup and implementation of the basic permission rules in part 1.

What does RBAC mean in this context?

We'll use RBAC as "Role Base Access Control", meaning your app will be using the following concepts to define who can access what:
  • "Who" is an existing user, mainly identified as his role in the system, such as an "admin" or "writer", etc.
  • "What" is a specific action in your application, identified as the associated routing params, for example ['controller' => 'Posts', 'action' => 'add'].
  • A permission in this context would be a link between who, and what.

Why not ACL?

ACL is a really good choice when your answer is 'yes' to any of the following questions:
  • Do we need to let users create new roles on the fly?
  • Do we need the roles to inherit permissions (tree structure)?
  • Do we need to assign permissions NOT based on controller actions? For example CRUD based permissions, checked on the model layer for each operation on a given row.
If your answer is yes, you should consider using cakephp/acl. It provides a very powerful, reliable and flexible way to configure your permissions, but with greater power comes a bigger maintenance burden, that is keeping the acl data in your tables. Specially if you have several environments to maintain, you'll need to write migrations to populate your acl tables, then create import/export scripts and utilities to reproduce permission issues from live environments, and so on. Not an impossible task, but could increase the complexity of your project in a significant way...

Setting up CakeDC/Auth

There are other plugins you could use, but this one will cover everything you'll need, so let's go. CakeDC/Auth usually comes installed from within CakeDC/Users (a complete solution covering many more features) but today we'll set it up alone. composer require cakedc/auth bin/cake plugin load CakeDC/Auth And last, but not least, add the RBAC Auth to the list of Authorize objects. Here is a working configuration based on the blog tutorial. We'll be using the blog tutorial described in the book as an example application Change AppController.php Auth related configuration to: $this->loadComponent('Auth', [ 'authorize' => ['CakeDC/Auth.SimpleRbac'], 'loginRedirect' => [ 'controller' => 'Articles', 'action' => 'index' ], 'logoutRedirect' => [ 'controller' => 'Pages', 'action' => 'display', 'home' ] ]); With this change, we'll be using only the rules defined in config/permissions.php file. If this file is not present, default permissions will be in place. Default permissions will grant access to admin role to all actions. To override permissions, you can copy the default permissions to your project and fix the rules: cp vendor/cakedc/auth/config/permissions.php config/ Then edit this file and check the provided examples and defaults.

Using CakeDC/Auth

The core of the RBAC system is the ability to define permission rules that will match one given role with the actions granted. Rules are defined in an array, but you can extend the AbstractProvider class to retrieve the rules from somewhere else (database?). By default, nothing will be granted. Rules are evaluated top to bottom. The first rule matched will stop the evaluation, and the authentication result will be provided by the value of the allowed key. Note we can use a callback to implement complex rules, or encapsulate the rules into classes that we could reuse across projects, like the Owner rule class provided. This is an example rule [ 'role' => '*', 'plugin' => 'CakeDC/Users', 'controller' => 'Users', 'action' => ['profile', 'logout'], ], We could read this rule as follows: "For any role, we grant access to actions 'profile' and 'logout' in the Users controller in plugin CakeDC/Users". Note default allowed value is true, we can use an array, or a string to determine the role, plugin, controller and action. We can also use * in the value to match anything or use * at the start of the key to match anything but the values, for example '*controller' => 'Users', would match all the controllers but 'Users'.

Simple Rules

As our first objective, we are going to grant access to all the index and view pages, using the rule [ 'role' => '*', 'controller' => '*', 'action' => ['index', 'view'], ],
Stay tuned for the second post, where we'll deal with complex rules, rule classes and implementation tips for complex applications...

We Bake with CakePHP