Partially tracked down another new issue that causing the "Permission restrictions deny" message to be displayed. Don't yet know if this is a problem with this module or http://www.drupal.org/project/securepages but linkchecker 6.x-2.4 did not have this problem. My sites have all admin pages served via https so when I look at the broken links report the URL is https://www.example.com/admin/reports/linkchecker. This is causing an issue because URLs in the $fields_with_node_links array have "https" where as the link being check has URL with "http"

e.g. link being checked http://www.example.com/ja/events $fields_with_node_links array contains:

https://www.example.com/events (Array, 1 element)
https://www.example.com/ja/events (Array, 1 element)

This causes if (empty($fields_with_node_links[$node->nid][$link->url])) to exit _linkchecker_link_node_ids(), which returns an empty array, and the "Permission ..." message is displayed.

When viewing http://www.example.com/admin/reports/linkchecker all links are "http" and everything works.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hass’s picture

This may be one of the known issues with local urls I may not able to solve :-(((. Can you try setting the hostname in settings.php? I'm not sure if it helps here, but it helped in past in some other situations. If you have any idea how to guess if we have a node that has local urls withs https or http I'm open minded to implement a fix.

tinker’s picture

Haas I don't think its going to be a difficult fix i just have not had the time to find it yet. I guess that since the report page, in my case, is being served using https there is something in the link checking code that uses the current page URL to convert relative URLs to absolute ones and its getting it wrong. I think it should assume http in all cases when converting relative and internal links.

hass’s picture

That's not correct and not that easy... There are sites outside that are HTTPS only. You need to know what the node itself defines (and this can only guessed) and this can change by module and custom rewrite url functions. I never worked with this custom rewrite url stuff and cannot say how, but secure pages may not the only module that implement SSL url's. Every pice of code need to be generic.

Have you set your hostname in settings.php - yes or no? Does it help?

tinker’s picture

Hi Haas, hostname was always set and is not the issue. This problem is only occurring for internal relative links e.g. "node/123". They are converted to absolute links using current page URL e.g https://www.example.com/admin/reports/linkchecker makes the link being checked https://www.example.com/node/123. Unless the hostname in settings.php specifically states it should use HTTPS it is safe to assume that HTTP should be used. Secure pages will pattern match and redirect HTTP to HTTPS pages. All absolute links are working properly and should not be affected by a possible patch.

hass’s picture

I think we need to ignore the protocol in _linkchecker_extract_node_links() function, variable $original_link:

          foreach ($link as $original_link) {
            if (strpos($item, $original_link) !== FALSE) {
              $field_names[$uri][$field_name] = $field_name;
            }
            // URLs in $links have been auto-decoded by DOMDocument->loadHTML
            // and does not provide the RAW url with html special chars.
            // NOTE: htmlspecialchars() is 30% slower than str_replace().
            elseif (strpos($item, str_replace('&', '&', $original_link)) !== FALSE) {
              $field_names[$uri][$field_name] = $field_name;
            }
          }
hass’s picture

Version: 6.x-2.5 » 7.x-1.x-dev
hass’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
FileSize
979 bytes

Could You give this patches a try, please? I do not have a SSL site for testing, so I'm blind and need your confirmation.

hass’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Status: Active » Needs review
FileSize
979 bytes

D6 version

AlexisWilke’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev

#8 did not work for me. I still get the error for a few of my links. Note that I did test everything as Admin (user 1).

Interestingly enough, it does not happen for all local paths since I had some broken links of local paths and fixed those just fine being able to see them there.

One of my "denied" link is 8743, so I tried this order and it returned 209 which is correct:

SELECT DISTINCT n.nid FROM node n INNER JOIN linkchecker_nodes ln ON ln.nid = n.nid WHERE ln.lid = 8743;

Note that I do not use i18n, however I have CCK fields. I'm thinking that somehow those are misused in some way and the returned list is empty interpreted as "you do not have enough permissions".

hass’s picture

Thanks for feedback. I have not been able to reproduce this issue myself. Can you try debugging the root cause, please?

minorOffense’s picture

I think it's related to the link missing either a node id, block id or comment id. If the link is sourced from an object which doesn't belong to those categories, access is blocked. I'm not sure how it gets into the database without an id (might have to do with Panels and such, since that's what all the pages are on my site).

Anyways, hopefully this helps. I should have a bit more time to debug in the following weeks.

balawang’s picture

Title: "Permission restrictions deny" message on many broken links when https securepages » A method not changing default protocal
Issue summary: View changes
Issue tags: +#ciandt-contrib
FileSize
1.54 KB

Drupal 7 only: The patch 1489132-linkchecker.patch intends to not change the protocal, but when testing the link, it tests for either http or https, but keep original link values.

balawang’s picture

Version: 6.x-2.x-dev » 7.x-1.2

Status: Needs review » Needs work

The last submitted patch, 12: 1489132-linkchecker.patch, failed testing.

balawang’s picture

Title: A method not changing default protocal » "Permission restrictions deny" message on many broken links when https securepages
Status: Needs work » Needs review
FileSize
1.54 KB

Corrected some mistakes on for #12, and re-upload the patch. ignore #12..
The patch is testing for both http and https, to ensure the permission check will pass, but not changing the link url itself.

Besides, is there a way to delete the mistakes??

bisonbleu’s picture

I just ran into this https issue. Patch works for me. Good work @balawang !

One very small detail: there are 9 occurrences of the word protocal in the patch. The proper spelling is: protocol. :-)

LiamPower’s picture