Links should not render if user does not have access

patch worked as designed :) Thanks. I did included file which includes your changes and http://drupal.org/node/996974. I dont know should I do it but it helps some people if there is some package which is patched and downloadable. Including myself.

a big thank you @kaido for this patch.
i wholeheartedly support the design decisions you explain in the description and appreciate the effort that you explain it.

patch applies cleanly and works like a charm.
code looks fine.
(at first i was puzzled about strtr($this->options['path'], $tokens); but this had to move some lines up which is fine)

* took the patch from the issue description
* reviewed the code as of: it does what it announces and has no serious style issues
(hey, it's 5 lines + comments, no big deal!)
* tested: link is rendered for user with access permission, not rendered if no permission

daring to raise prio as i wouold call this expected behavior

+1 for your application ;-)
you may count me in for limited help.

Patch works great and should be integrated into the next release!!

Perhaps this would have been an alternative:
http://api.drupal.org/api/drupal/includes!path.inc/function/drupal_valid_path/7

The patch has been integrated into the latest 7.x-1.x DEV release.

Please test and review it. If everything is fine with this dev release I will create a new stable release asap!

You are right in #10 - our code essentially tries to duplicate drupal_valid_path().
So factoring that out is most kitten friendly.

Here's a followup patch for that.
I'm using it in production.

Patch makes sense, though as it's a cleanup it does confuse this issue a bit.

Needs a couple of tweaks to conform to coding standards though:

+++ b/views_handler_area_link.inc
@@ -86,11 +86,8 @@ class views_handler_area_link extends views_handler_area {
+      if(!drupal_valid_path($path)) {

You need a space after the 'if'. Also the comment should be wrapped to 80 lines.

Ran the patch from #14 through the Drupal coding standards fixer tool in TextMate. Should be good now.

Patch applies cleanly and access is (still) honored.

Just needs a few tweaks, sorry!

1. +++ b/views_handler_area_link.inc
   @@ -1,7 +1,5 @@
    <?php
   -
    class views_handler_area_link extends views_handler_area {
   -
   
   @@ -139,3 +135,4 @@ class views_handler_area_link extends views_handler_area {
    }
   +
   

   Patch has surplus whitespace changes I'm afraid.

2. +++ b/views_handler_area_link.inc
   @@ -86,11 +85,8 @@ class views_handler_area_link extends views_handler_area {
   +      // Check that path is valid and user has access to it. External paths are fine.
   

   This line needs to be wrapped to 80 chars.

You mean the comment needs to be trimmed to 80? Not the class definition right?

As for the whitespace I'll remove it.

Yup, comments need to be wrapped to 80. The class def is fine.

Quick reroll of the patch with phpcs errors avoided with an interdiff between this and #16.

Patch has unrelated changes I'm afraid:

1. +++ b/views_handler_area_link.inc
   @@ -1,7 +1,5 @@
   -
    class views_handler_area_link extends views_handler_area {
   -
   

   Still has these whitespace fixes which aren't relevant.

2. +++ b/views_handler_area_link.inc
   @@ -45,7 +43,8 @@ class views_handler_area_link extends views_handler_area {
   -    $count = 0; // This lets us prepare the key as we want it printed.
   +    // This lets us prepare the key as we want it printed.
   +    $count = 0;
   

   This is a fix, but again an unrelated one.

Ah! I think I finally understand what you're talking about. :)

Here's hopefully the last patch, which really and truly solves the problem (as was done in #14) without adding unrelated PHPCS changes AND without adding any new PHPCS errors.

I'm including an interdiff between 14 and this as well.

Code is beautiful ;-)

Hi Thanks!

it works for me,
did not know that patch #23 was already included in the current dev.

so this is fixed as of #23.

We really need #2455609: Create 7.x-1.1 release...