Subscribe: blog.phpdeveloper.org
http://blog.phpdeveloper.org/?feed=atom
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
based  check  drupal  evaluation  gatekeeper  good  groups  invoke  make  new  permissions  project  psr  security  user 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: blog.phpdeveloper.org

blog.phpdev





Updated: 2017-12-28T19:01:59Z

 



WordPress.comSaying Thanks – Open Source Appreciation

2017-12-21T17:29:20Z

Wow, it has been a really long time since I’ve posted here. Most of my writing has ended up in articles of php[architect] or over on Websec.io. I wanted to jump back into the blog though and talk about something inspired by a post over on the Symfony blog about giving thanks. Normally the Thanksgiving […](image)

Wow, it has been a really long time since I’ve posted here. Most of my writing has ended up in articles of php[architect] or over on Websec.io. I wanted to jump back into the blog though and talk about something inspired by a post over on the Symfony blog about giving thanks.

Normally the Thanksgiving holiday is more associated with sharing what you’re thankful for in your life. However, the Christmas holiday comes at a perfect time to look back over the past year and think about everything you’re thankful for and how your life has changed, hopefully for the better. In the Symfony blog post they share a Composer plugin – Thanks – that makes it simple to show your appreciation to those packages you’re currently using in your applications. It sends stars to the projects (the ones you haven’t already starred naturally) as a token of appreciation. This is a great first step to showing how much you appreciate the work the maintainers have done but there’s also other ways to show that you support them and that they’re doing a great job. Here’s a few other suggestions:

  • Find their email (often in the repo’s README.md file) and send them a quick note telling them how much you enjoy using the library and how important it is to your application.
  • Write a blog post about the package and how you use it to share with others. Maintainers always enjoy seeing how their work is used and maybe even get ideas for future features and fixes.
  • Send out a Tweet about the project, telling them how much you appreciate the work they do.
  • Support them on Patreon if they have a page on there with a recurring donation. This allows them to spend more time focusing on the project and making it better for everyone.
  • Open an issue on the project’s Github/Bitbucket repository with a quick “Thanks” to everyone involved.

These are just a few ideas to get you started, of course. There’s plenty of other ways that you can support and thank the authors and maintainers of your favorite packages. Get creative and think of your own but this is the perfect time of year to do it and let those developers know their work is appreciated!


(image) (image)



Protecting your application with PropAuth (Property-based Policy evaluation)

2015-12-30T13:42:53Z

Library: PropAuth (Property-based policy evaluation) I’ve been working on a library for a while now that kind of distills down some of the ideas of property-based authorization (like XACML) and makes it a bit more accessible to the average developer. Property-based evaluation can be a little tricky to get your head around if you’re used […]Library: PropAuth (Property-based policy evaluation) I’ve been working on a library for a while now that kind of distills down some of the ideas of property-based authorization (like XACML) and makes it a bit more accessible to the average developer. Property-based evaluation can be a little tricky to get your head around if you’re used to the usual RBAC world. Let me introduce it briefly. Property-based evaluation is more or less what it sounds like: a system checks the properties of an object (or objects) and looks for different kinds of matches. That much is pretty simple but then you get into the “policies” aspect. This is where the real power comes in. With policies you can define the pass/fail requirements for the checks against an object and see if there’s a good enough match. With something like XACML it gets pretty complicated as it defines policies with XML documents (and we all know how “simple” XML is). There’s all sorts of different combining algorithms for the results like “first wins” or “all must match”. These can, of course, be nested and combined themselves leading to pretty complex policies and a mess if you’re not careful. So, back to PropAuth now. In the work that I’ve been doing I’ve only really seen the need for a more streamlined version of this kind of evaluation. Some of the overall flexibility that XACML provides hasn’t been included in PropAuth, but I haven’t found much of a need for that so far anyway (like nested policies). The PropAuth library provides some of the basic property evaluation handling and policy creation I think could replace a lot of the mish-mash of role-based access control functionality out there and make for much more reusable code. First off, to install just use Composer: composer require psecio/propauth And here’s a simple example of a policy evaluation: 'ccornutt' ]; $myPolicy = new \Psecio\PropAuth\Policy(); $myPolicy->hasUsername('ccornutt'); echo 'Result: '.var_export($enforcer->evaluate($myUser, $myPolicy), true); ?> Here’s a quick summary of what’s happening here: the Enforcer object is the “frontend” that handles most of the work. You pass in a subject for the evaluation and the policy to evaluate against. In this case I’ve used the “hasUsername” check to look at the “username” property on the object and check to see if it matches the “ccornutt” value. The “evaluate” method is then called and a true/false result is returned…in this case true as our “myUser” object has a matching username. This only scratches the surface of what the PropAuth library can do but it gives you an idea of how the evaluations are set up. There’s also a simplified interface you can use with the same library to perform an authentication of a user with a system that uses bcrypted passwords (like with the password hashing API): 'ccornutt', 'password' => password_hash('test1234', PASSWORD_DEFAULT) ]; $gate = new \Psecio\PropAuth\Gateway($myUser); $subject = $gate->authenticate($password); ?> If the password matches, you’ll be given an authenticated version of the “subject” back from the “authenticate” call. If not, you’ll get a false back on failure. Naturally[...]



Custom Callbacks with Invoke

2015-07-26T12:59:42Z

In putting the Invoke library to use I noticed something. While I could tell it to check for groups and permissions on the current user and limit HTTP methods on the request, there were more complex things I needed to check that weren’t part of these defaults. Now, I could just extend invoke to include […](image)

In putting the Invoke library to use I noticed something. While I could tell it to check for groups and permissions on the current user and limit HTTP methods on the request, there were more complex things I needed to check that weren’t part of these defaults. Now, I could just extend invoke to include match types for everything I needed (injecting a custom match class based on my needs) but I wanted something a bit more generic that I could use to call my own logic and return the pass/fail result.

So, I added in the “object.callback” match type that allows you to call a static method in your own code and perform the evaluation yourself. Here’s how it works. Say you have this configuration in your routes.yml file:

/foo:
  protected: on
  callback: \App\MyUser::test

This tells Invoke that when the user requests the /foo URL, the protection should kick in. It then goes into the checks portion of the process. This sees the special callback option and looks the class and method to call. In this case, we’ve told it to try calling the test method \App\MyUser. This class needs to be autoloadable so that Invoke can directly call it and its static method. Yep, that’s right – it needs to be a static method but you’ll be provided with everything about the request in the incoming $data variable. Here’s what the method should look like:

public static function test(\Psecio\Invoke\Data $data)
{
  /* perform your evaluation here and return a boolean */
}

In the $data variable there, you’ll have access to the context of the application via some object properties:

  • user: The current InvokeUser instance (ideally where your user lies too)
  • resource: The resource that was requested (includes access to the requested URI)
  • route: This is the route match from Invoke’s configuration the current request matches. This contains the route regex match, the configuration options and any additional parameters passed along

For example, say you needed to get the parameters from the request to do further evaluation. You could fetch them through $data->resource->getParams() and get the associative array back.

Adding these callbacks makes the Invoke system a lot more flexible and allows you to create those custom match types without having to have whole other classes just to perform your checks.


(image) (image)



Laravel Route Protection with Invoke

2015-06-24T22:54:42Z

I started on a tool a while back to “scratch an itch” in a personal project to make it easier to protect endpoints based on the requested URL. The Invoke library makes it possible to detect the route requested and ensure a set of criteria are met to be sure a user can access a […]I started on a tool a while back to “scratch an itch” in a personal project to make it easier to protect endpoints based on the requested URL. The Invoke library makes it possible to detect the route requested and ensure a set of criteria are met to be sure a user can access a resource. This isn’t anything new or revolutionary, but it is something I couldn’t find separate and effectively decoupled from other tools. It’s loosely based on how Symfony (v1) does it’s route protection, right down to the .yaml file that it uses for configuration. In my case, I was using it in a Slim framework-based application to evaluate the current user to see if they had the required groups and permissions. More recently, though, I’ve been messing with Laravel and since they’ve been putting a heavy emphasis on middleware, I thought I’d see how tough an integration might be. I wanted to use Invoke to check my Laravel user to see if they met my requirements. Fortunately, it turned out to be super easy. Here’s how I did it – hopefully it can be useful for you. I’ll provide one caveat though: Laravel’s default auth handling only sets up users, not groups/permissions, so you’ll need a way to manage those but that’s outside the scope of this. You’ll see how it integrates in a bit. First off, we need to get Invoke installed via Composer: composer require psecio/invoke Once that’s installed, we need to set up our middleware. This will go in with the rest of the default middleware in the app/Http/Middleware folder in your application. Create a file called InvokeMiddleware.php with this code: isAuthorized( new \App\InvokeUser($user), new \Psecio\Invoke\Resource($request->path()) ); if ($allowed !== true) { return response('Unauthorized.', 401); } return $next($request); } } You’ll see there’s a reference to an InvokeUser class in there. Let’s make that next. In app/InvokeUser.php put this code: user = $user; } public function getGroups() { // This is where you fetch groups return []; } public function getPermissions() { // This is where you fetch permissions return []; } public function isAuthed() { return ($this->user !== null); } } Then, to turn it on, edit your app/Http/Kernel.php class and add this to the list of $middleware: \App\Http\Middleware\InvokeMiddleware::class, Viola, you’re set to go using Invoke. Now, the next step is to define your rules. You’ll notice in the middleware above we’re loading the config/routes.yml configuration file for our rules. Let’s make one of those with a super simple example. In app/config/routes.yml put: /: protected: on This configuration is telling Invoke that, when you hit the base URL of your application (“/”) it’s protected. This means th[...]



Why Drupal’s Bug Bounty is Important

2015-06-05T00:54:17Z

The Drupal project has just announced a bug bounty program where they’re offering sums between $50-1000 USD for anyone who finds and reports a security issue with Drupal 8: Drupal 8 is nearing release, and with all the big architectural changes it brings, we want to ensure D8 upholds the same level of security as […]The Drupal project has just announced a bug bounty program where they’re offering sums between $50-1000 USD for anyone who finds and reports a security issue with Drupal 8: Drupal 8 is nearing release, and with all the big architectural changes it brings, we want to ensure D8 upholds the same level of security as our previous releases. That’s where you come in! The security team is using monies from the D8 Accelerate fund to pay for valid security issues found in Drupal 8, from now until August 31, 2015 (open to extension). This program is open for participation by anyone. One thing to note, they’re only looking for Drupal 8 issues here, not problems in past editions (I’m sure they’d still appreciate them being reported though). There’s some stipulations they list where the vulnerability doesn’t count including someone with Administer level access and several other very specific kinds of issues. I’m assuming they’ve already run some pretty extensive testing on those, though, otherwise they would’ve been included in the list of allowed vulnerabilities. A mention of the bug bounty was posted over on the /r/php subreddit earlier and there’s already some good feedback about it. There’s two points that I want to touch on as to why Drupal announcing this bounty is a major and important thing for the entire PHP community, not just Drupal. First off, it sends a message to the wider world of developers that it’s time to take (PHP) security seriously. PHP’s had a less than stellar reputation when it comes to security. Fortunately it seems like things are getting better and more developers are working towards building secure applications. Security is a hot topic everywhere, not just in development communities and it’s starting to rub off on PHP devs. This bold move from the Drupal organization takes that up to the next level. It’s essentially telling everyone that uses Drupal or has any kind of contact with it, that they’re taking the security of their systems seriously and are “putting their money where their mouth is” to encourage as much participation as possible. Bold moves like this are what get people’s attention too, even people not in the PHP community. Bug bounties have become a pretty common place thing in the security world, for software and hardware alike. By posting this bounty Drupal has shown that they (and vicariously PHP) are ready to move up and join with the security community as a whole to make their software more secure. Not only does this look good for Drupal but it looks good for PHP too, elevating the status of the language back to a “major contender” in the security circles. Second, it helps pave the way for other projects to do the same. Most PHP projects tend to be smaller, not only in size but in complexity. There’s only a handful that most PHP developers can immediately list that are larger and have really stood the test of time. Keep in mind, I’m not talking about corporate applications or services here. I’m talking about PHP-based applications like Drupal, WordPress or Joomla that can be used as a platform to build other things. For the most part, their PHP brethren trend more towards the smaller side. Some of the most popular packages on Packagist are smaller libraries and frameworks, not applications as a whole. There are some larger projects, though. Frameworks like the Zend Framework and Symfony have put their own emphasis on security, having internal groups or just contributors handling the vulnerability discovery [...]



Gatekeeper & Policies

2015-06-01T15:21:45Z

I’ve been working on a system for a while now, inspired by the work that was done on the Sentry project, to provide a role-based access control system that was not only more well-maintained but also built on the foundation they provided to add in some new features. My “little project” Gatekeeper has really grown […]I’ve been working on a system for a while now, inspired by the work that was done on the Sentry project, to provide a role-based access control system that was not only more well-maintained but also built on the foundation they provided to add in some new features. My “little project” Gatekeeper has really grown over time and (I think) really evolved into something that’s quite useful. With this progression in mind, I’ve recently added another new feature that sits on top of the permissions and groups system that allows you to create reusable policies. Policies are a common concept when it comes to access control. They can make performing complex operations a lot simpler and, in the case of how it’s implemented here, make it much more reusable across the entire system (or multiple systems). Checking user permissions and groups is a relatively simple operation if you’re just doing one or two checks. You’d end up with something like this: inGroup("group1") && $user->hasPermission("perm1")) { echo "Good to go!"; } ?> In this case, the check is relatively simple but there’s one think that any DRY code advocate could tell you – this exact check would need to be reproduced throughout the entire application exactly as stated to ensure the evaluation is the same. Even worse, if the requirements changed you’d have to work across the entire application and replace all instances with the new logic. This is where policies can come in very handy. With the functionality that Gatekeeper includes, they’re dead simple to use too. The key is in their use of the Symfony Expression Language component. This language allows you to define text strings that represent logic and allow for more complex and self-contained evaluation. Enough talk, let’s see how we can use these policies to perform the same check as above. 'admin-test1', 'expression' => '"group1" in user.groups.getName() and "perm1" in user.permissions.getName()', 'description' => 'See if a user has "permission1" and is in "group1"' )); // Now, we need to evaluate the user against the policy if (Gatekeeper::evaluatePolicy('admin-test1', $user) === true) { echo 'They have the permission! Rock on!'; } ?> It’s a little more verbose than the previous example, but you can see how it would fetch the permissions and groups for the user and check it against the set of names. In this case the getName function is a magic method that filters the collection and returns a set of the name property values as an array. This way it can be used with the incheck. Once the policy is in place, then any time you need to perform that evaluation, all you need to do is call the evaluatePolicy method with the information and it will always execute the same logic making it super portable and DRY. I also mentioned how it helps with changing requirements. All you’d need to do here is change the policy contents (the expression string) and all of the code already in place will now evaluate with that new logic with no code changes required. Easy, huh? I hope this functionality will be useful if you’re a Gatekeeper user or, if you’re not, may give you a reason to check it out. I’m also intere[...]



PHP, Security & PSR-9/PSR-10

2015-05-22T12:36:30Z

Late yesterday afternoon the PSR-9 and PSR-10 drafts were moved into master on the php-fig/standards repository, moving them along to the next step and to get the wider perspective of the main PHP-FIG group’s opinions on it. What are PSR-9 and PSR-10, you ask? Here’s a brief summary so far: At the end of last […]Late yesterday afternoon the PSR-9 and PSR-10 drafts were moved into master on the php-fig/standards repository, moving them along to the next step and to get the wider perspective of the main PHP-FIG group’s opinions on it. What are PSR-9 and PSR-10, you ask? Here’s a brief summary so far: At the end of last year (2014) Lukas Smith made a proposal to the PHP-FIG group for a standard that would make reporting security issues with PHP projects and libraries a much more structured thing. The general idea is that a standardized document (or documents?) in a project’s repository would provide information about current and past security issues in a well-defined structure that could have some automated tooling around it. Much discussion was had around what the proposal actually entailed and how it would integrate with the goals of the PHP-FIG process. As work progressed on it, a few others besides Lukas came on-board to help flesh out the standard and work out the kinks, including myself. It wasn’t long before we realized that, while having a standardized method for reporting vulnerabilities was good there also needed to be a way to discover this documentation for a given project (more than just a “look for this file” kind of thing). So, the original PSR-9 was split, giving us the security advisory reporting standard (PSR-9) and the security disclosure workflow (PSR-10) to make discovery of the reports easier. Both PSRs have received the votes needed for entrance and consideration and, as I mentioned, work is moving forward on them in the wider PHP-FIG group. So, what are the standards? Well, I’m not going to just copy and paste from the documents (you can find those here if you’re interested) but I will give a quick overview of what they contain and their goals. Note: these standards are by no means complete so this information is a bit subject to change. I just wanted to share their current state though. PSR-9 The main goal of the PSR-9 standard is to provide structure around the documentation a project provides to the wider community around security vulnerabilities that have been found (and fixed) and those that are still pending. The idea is that any given user could look at the document and have a security-centric view into where the project currently stands. Right now, with the exception of those participating in the security-advisories database, most projects make it a bit of a run around to try to figure out what issues have come up and what problems have been fixed. Sometimes it’s reported in the Changelog, other times it’s in the mailing lists and other times you just have to know what to search for in the project’s issue tracker to get the list. This PSR-9 aims to eliminate a lot of this hassle and give a single source for the information. The security-advisories database has provided a great start around this same kind of information but with PSR-9 the burden of reporting this information falls on the project, not a single source. We’re not aiming to replace that database by any means, though. We just want to empower the projects to share the information in a vetted, well-defined way. The PSR-9 proposal provides a lot more context around the security issues too. This information includes: An entry for each vulnerability that includes a short summary, published date, link to more information and a unique reference ID CWE and/or CVE information, if possible (not all vulnerabilities are reported as CVEs) What versions the issue affects Current status of the[...]



Speaking at AppSec USA 2015

2015-05-15T16:09:59Z

It’s always good to step outside of your usual bubble and try something new every once and a while. I recently took this step and submitted for the AppSec USA 2015 conference happening in San Francisco on September. My topic? PHP security, naturally but it’s to a much more diverse audience. At PHP conferences its […](image)

It’s always good to step outside of your usual bubble and try something new every once and a while. I recently took this step and submitted for the AppSec USA 2015 conference happening in San Francisco on September. My topic? PHP security, naturally but it’s to a much more diverse audience. At PHP conferences its easy to take a lot of things for granted. You’re able to assume that most of the people in the room are developers and understand what PHP’s all about and have at least a little experience with it. At AppSec I don’t really have that guarantee so it’ll be interesting to see how it turns out.

Here’s my prospectus for those that are interested:

PHP Security, Redefined

Let’s be honest, PHP has had a rocky history with security. Over the years the language has been highly criticized for it’s lack of a focus on security and secure development practices. In more recent years, however, a resurgence has happened in the language and community, bringing secure development back into focus. With PHP 7 on the horizon, the language is making even more strides to improve some of its wayward ways of the past and reinvent itself. I’ll share practical code examples, tools, libraries and best practices that are making it easier than ever to keep PHP applications safe.

Come along with me as I guide you through both the language improvements and community encouragement making PHP a more secure place.

I’m hoping that, while the talk is more specifically about PHP security, that it will also be a good platform to help some in the information security community shatter some of their own misconceptions about PHP (ones that are probably stuck in the late PHP 4 to early PHP 5 days). I’m excited to get to talk about PHP7 too which, if all goes well, should be in its final stages by the time the conference rolls around in September.

When I got the acceptance email, I felt that same feeling down in the pit of my stomach I felt when I first was accepted to php[tek] so many years ago. Now it’s a good feeling, though – one that’s more excitement than worry, more encouragement than stress.


(image) (image)



Social Security

2015-04-30T15:07:35Z

Let me preface this by saying I think that sharing knowledge and experiences is a great thing. I love that there’s so many tutorials out there from people showing good practices in security and things they’ve learned along the way. Unfortunately, this is the same place where I see a major downfall. This kind of […]Let me preface this by saying I think that sharing knowledge and experiences is a great thing. I love that there’s so many tutorials out there from people showing good practices in security and things they’ve learned along the way. Unfortunately, this is the same place where I see a major downfall. This kind of “social security” is a problem and it needs fixing so secure application development can really thrive. Technology is great, especially PHP. Sure, there’ll be haters out there and they’ll throw stones at the glass house that is PHP hoping to break down the walls and push it off away from the public eye and into the “Not A Real Language” world. Fortunately, this will never happen especially with more recent improvements to the language and its consistent popularity among web developers. PHP is both easy to pick up but difficult to master, especially when it comes to the security of the applications written with it. Along with this low barrier for entry comes people sharing things either in tutorials or just articles that they’ve found to be useful or think is a good practice. The web is littered with articles like these, some being a bit more factual than others. *This is where the real problem is.* Well-meaning developers post tutorials about things like preventing XSS with just htmlspecialchars or only fixing SQL injection with prepared statements and bound parameters. While these are good practices in themselves, they’re not the only thing that needs to be done to prevent these issues. Security is a complicated subject and there’s no one answer to any problem. Usually a robust solution involves multiple layers (defense in depth anyone?) to ensure the problem doesn’t pop up again or in another location. Even worse are the numerous older articles posted around the internet that have bad or old information. Sadly I see some of these that are *years* old being recommended as good resources to learn from. I see two kinds of resources out there: Those that are posts from individuals or groups and are wholly maintained by them community resources such as the OWASP wiki I’ve done some picking on OWASP in the past about the quality of their PHP materials and what seems to be their general feel around PHP and PHP-centric security. This time, though, I don’t want to talk as much about their content itself but about the process they follow for generating that content. I appreciate what OWASP is going for application security, I really do, but I think the “everyone can edit” mentality of their content is very flawed. I know it’s just not feasible for a single organization largely made up of volunteers to manage and audit all of the content on their site. I get that, I really do, but when I see people referring to PHP resources that haven’t been updated since 2006 or 2007 it makes me cringe. And, because of the visibility of the group, those are the resources people find and recommend not knowing any different. I think this is the crux of my opinion – having resources where anyone can contribute and not auditing those resources is a “Bad Thing” in my book. Unfortunately, in the case of the masses of tutorials posted out on the web, there’s not much that can be done about that. Those are there to stay and search engines will continue to ensure they show in results regardless of their quality or relevance to the current state of things. I’m not s[...]



Invoke and Gatekeeper for Route Authentication & Authorization

2015-04-24T13:00:09Z

As a part of a new project I’m working on (personal, not work) I came across a common need to enforce authentication and authorization handling in a bit more automated way based on the URL requested. I looked around for options and didn’t really find many that could be implemented somewhat simply but I did […]As a part of a new project I’m working on (personal, not work) I came across a common need to enforce authentication and authorization handling in a bit more automated way based on the URL requested. I looked around for options and didn’t really find many that could be implemented somewhat simply but I did like the way Symfony defines their YAML to enforce auth* on the various endpoints. I set out to make something similar but a little simpler and ended up making Invoke. It’s a super simplified version of the YAML-based routing and only has functionality for checking groups and permissions right now, but that’s not what I really wanted to talk about in this post. Invoke is fun and all, but I wanted to show how I’ve integrated it with another more robust tool I’ve written, Gatekeeper. The goal of Gatekeeper is to make a simple drop-in authentication system for applications to take care of a lot of the boilerplate user management needs. It comes with the usual CRUD handling for users, groups and permissions (RBAC) and also supports password resets, security questions and “remember me” functionality. Again, Gatekeeper is a cool library but it’s not the primary focus here. I wanted to integrate the two libraries so I could let each do what they do best – Invoke to check the current user against a set of criteria and Gatekeeper to provide the data for this validation. Invoke lets you hook in your own users via a `UserInterface` that you can implement in your own application. In this case Gatekeeper has a concept of users too, but they don’t exactly mesh with what Invoke is expecting. So, let’s make an Invoke-compatible user object that it can use for it’s checks. This is the real key to the integration: details = $details; } public function getGroups() { $groupSet = array(); $groups = Gatekeeper::findUserById($this->details['id'])->groups; foreach ($groups as $group) { $groupSet[] = new InvokeGroup($group); } return $groupSet; } public function getPermissions() { $permSet = array(); $permissions = Gatekeeper::findUserById($this->details['id'])->permissions; foreach ($permissions as $permission) { $permSet[] = new InvokePermission($permission); } return $permSet; } } ?> Then, we’ll define the Invoke configuration in a YAML document: event/add: protected: on groups: [test] permissions: [perm1] In this case we’re telling Invoke that when it sees the requested URL of `/event/add` it should check a few things: That the user is authenticated (protected: on) That the user has a group with the “name” attribute of “test” That the user has a permissions with the “name” attribute of “perm1” If the user passes all of these checks, they’re good to go. Here’s how that would look in the execution of the Invoke code: toArray(); // Otherwise you can push in your own user data $u[...]