Not Authorized when managing flexible layout

We can confirm that the 3.6 update introduced this issue, and 3.7 fails to resolve the issue.

To recreate:

1. On simplytest.me, start a 7.50 sandbox with ctools and panels.
2. Create a user, don't use user/1.
3. Navigate to admin/structure/panels/layouts/add-flexible
4. Try to add a region to a row. You'll see the "You are not authorized to access this page." warning pops up.

We're not using flexible layouts, so we're not directly compromised.

Subscribing.

We are experiencing the same issue. Using flexible layouts and as soon as I try to add a row or column the "You are not authorized to view this page" message is received.

I'm able to confirm that this bug exists in Panels 3.7. However, for me, applying the patch from #2787637-6: Page manager gives access denied when managing newly added variants to tasks other than 'page' fixes it. The issue description says that the OP tried that, but it didn't fix it. :-/

Can someone give step-by-step instructions for reproducing this even with that patch applied?

Unfortunately, if I can't get it to break, I can't help to fix it... Thanks!

Interesting. I can not apply #2787637-6: Page manager gives access denied when managing newly added variants to tasks other than 'page' to simplytest.me so I had to create a test site locally.

I am still seeing "You are not authorized to access this page."

To recreate locally:

1. Create a 7.50 instance locally. Use the "minimal" profile.
2. Download ctools and panels. Enable them.
3. Apply patch https://www.drupal.org/comment/11536195#comment-11536195 to panels
4. Create an "Admin" role and grant all permissions to "Admin"
5. Create a second user and grant the role "Admin" to this user.
6. Log out and back in as the second user.
7. Navigate to `admin/structure/panels/layouts/add-flexible`
8. Try to add a region to a row. You'll see the "You are not authorized to access this page." warning pops up.

Dev environment configuration:

1. php 5.5.33
2. apache 2.4.18
3. mysql 5.5.48-37.8-log

Enabled modules:

 Package           Name                                   Type    Version  
 Chaos tool suite  Chaos tools (ctools)                   Module  7.x-1.10 
 Core              Block (block)                          Module  7.50     
 Core              Database logging (dblog)               Module  7.50     
 Core              Field (field)                          Module  7.50     
 Core              Field SQL storage (field_sql_storage)  Module  7.50     
 Core              Filter (filter)                        Module  7.50     
 Core              Node (node)                            Module  7.50     
 Core              System (system)                        Module  7.50     
 Core              Text (text)                            Module  7.50     
 Core              User (user)                            Module  7.50     
 Panels            Panels (panels)                        Module  7.x-3.7  
 Core              Bartik (bartik)                        Theme   7.50 

Will a layout ever have a storage type?

I've added a check to see if editing_layout, not sure this is correct approach to address this issue, but have not had time to review this in detail.

The patch submitted is against 7.x-3.7 so can't be applied to dev.

When editing the layout, we need to check the storage_type/id of the panels display that it's on. The layout itself won't ever have a storage_type/id, though.

Surely sometimes the layout will not be associated to any display?

For instance if you were to go to /admin/structure/panels/layouts, and click add flexible layout.

Ok, I see why I failed to reproduce this! I kept creating a flexible layout as part of a Panels display, and totally blew pass the admin/structure/panels/layouts/add-flexible link. Sorry, everyone!

So, this happens when creating a reusable flexible layout that isn't part of a Panels display.

The thing is that at the API level, I think that a flexible layout is always part of a Panels display (right?), so that UI has got to be creating a temporary, fake Panels display or something like that? We'll need to check a special set of permissions in that case, but continue to check the normal permissions when the settings for the flexible layout are on a real display. Maybe we could have a special storage plugin just for use in that UI?

This is my best guess on where the fake Panels display is created:

http://cgit.drupalcode.org/panels/tree/plugins/export_ui/panels_layouts_...

If we did decided to create a storage plugin for handling this case, this would be the place (if my guess is correct) to set that.

deranga; the patch works here against 3.7 (not dev) following the same steps I outline in #8

dsnopek; if my report in #8 about step 7; "Navigate to admin/structure/panels/layouts/add-flexible" was ambiguous, please let me know.

@Screenack: No your report was fine, it was my mistake. Sorry!

Ok, just so the patch I attached makes more sense when reading I've adjusted the comment and removed the unnecessary extra line.

Is there any reason to also implement the new security measure for layouts, or is a simple user_access check for that permission good enough here?

Again attached patch is against 7.x-3.7 (not dev)

Is there any reason to also implement the new security measure for layouts, or is a simple user_access check for that permission good enough here?

Well, if we just check user_access('administer panels layouts') that means that anyone with that permission would be able to change the flexible layout on any Panels display, even if they don't have permission to edit the underlying display. So, the current patch works for reusable flexible layouts that aren't on a Panels display, but potentially opens up a security hole for flexible layouts that aren't reusable, but just part of a single display.

EDIT: I should note that I haven't actually tested that it opens up a new problem, just that that's why we need to be sure to test both cases and the final solution might end up being more complicated.

Okay, sure - definitely don't want to open up and perhaps the code change I'm suggesting should be nested to not disrupt the new storage type permission check flow:

    if (empty($this->storage_type) || empty($this->storage_id)) {
      //if we are editing layout
      if($this->editing_layout){
        return user_access('administer panels layouts');
      }
      return FALSE;
    }

Just so I'm clear on this, in what ways can you currently restrict the access to creating/editing a display irrespective of the layout?

I didn't think that the permissions offered by panels were that granular?

Patch based on last comment as realised that original patch would have subverted current permission check flow

I can confirm that the patch in #19 works. Can we use the Drupal-recommended naming convention for uploading patches? This will help disambiguate which patch we're talking about.

layout_issue_1.patch should be

panels-flexlayoutperms-2790075-20-7x.patch

I've taken your patch and renamed it to standard.

@Screenack - apologies, you are right, I should be using the naming convention.

Although this patch works, as @dsnopek mentions, this is quite a simplistic fix, and may not be the appropriate way to address.

Where the `fake` display is generated if one is not associated to the layout in http://cgit.drupalcode.org/panels/tree/plugins/export_ui/panels_layouts_... is likely the correct place to add in a storage type and id:

So adding something like this after line 75 and before line 82:

$display->storage_type = 'page_manager';
$display->storage_id = 'new';

What I don't follow hence the questions, is what benefit there would be in adding a storage type and storage id in this instance - I don't follow what granular permissions can be set to grant editing of a layout. Also, I'd need to understand more about how the storage type and id are handled; any pointers @dsnopek?

Here's a patch with what I was thinking for this. It works in my testing, however, you'll need to clear the cache (so Panels picks up the new plugin) and if you previously started editing a particular flexible layout, you may need to save it for the change to take effect (because the old Panels display will already be cached in the CTools object cache).

Please let me know if this works for the folks who were having the problem!

This patch successfully addresses the warning, using the steps I outlined in #8, but using the latest patch.

Bumping to 3.9.

Current Setup:

• Panels 3.8
• CTools 1.11
• Panelizer 3.4

On a new installation of 7.51 I installed the above modules. I then navigated to Admin -> Structure -> Panels -> Layouts and added a new custom layout without any customizations other than setting the title. After that I went to edit the layout.

From Column I selected "Add row to top" and was greeted with the "You are not authorized" alert. That left the modal panel up in a spinning loading state so I closed it.
After that I selected "Add region to left" from Row and was greeted with the same functionality of alert and the modal window sticking.
This behavior follows for {Canvas,Column,Row,Region} settings, adding to {Canvas,Column,Row} removing a {Column,Row,Region}.

The above patch (#22) solves this issue. It's impossible to make changes to a custom layout without that patch and I certainly feel that this should be addressed in the next release of Panels #2819117: Plan for Panels 7.x-3.9 release.

+++ b/plugins/panels_storage/panels_layouts_ui.inc
@@ -0,0 +1,18 @@
+// Plugin definition

This line of code is missing a full-stop. (Drupal.Commenting.InlineComment.InvalidEndChar)
The new panels storage / layout plugin that defines access looks like is was modeled off of plugins/panels_storage/page_manager.inc and this exists there as well.

I have attached a new patch with this small Code Standards piece fixed. Other than that it looks good to go for the 3.9 release and addresses all of the "You are not authorized" messages that were previously occurring.

I've reviewed the changes between #22 and #26 and can confirm there *only* difference is a period, I guess @dasginganinja cleans their glasses more often than the rest of us ;-)

This was committed and will be in the next release.

Thanks Damien, yah I was on a plane and d.o was being.. slow :) Fixed!

this doesn't patch with version 3.4 of panelizer?