The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Apparently, Link Checker looks at all nodes and blocks independent of node access. However, if the internal (!) link targets are protected by some node access module, they will cause failures, even if the target would be visible to those who can see the link source.
I think Link Checker should check internal links as user 1.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | check_as_user_1-2837780-8.patch | 1.82 KB | salvis |
Comments
Comment #2
hass commentedThat may be useful for a specific example, but the intention of the module was to make sure things linked in public do not have death links. If you remove content from public it may no longer accessible for all users except admin. I'm not sure if this may also introduce a security issue? But maybe we can implement it properly so it works for both anonymous and user1.
Comment #3
salvisThank you for your reply, hass!
I can say for sure that Link Checker scans forum topics that are protected by Forum Access (node access) as well as blocks that are restricted by core to certain roles. These links are definitely not visible in public, but Link Checker flags them because the link targets are not visible in public either.
This results in hundreds of bogus Link Checker errors. The protected Tagadelic tag cloud blocks alone each have 30 bogus bad links to protected terms. This large number of bogus bad links makes Link Checker unusable in my set-up, especially because you can whitelist link targets but not link sources, and you can whitelist the link targets only one at a time.
Obviously, it would be fantastic if Link Checker could take all access mechanisms into account and verify that the target's access is a superset of the source's, but this is just not feasible. Looking for a compromise, I think it would be useful to just verify that the internal link targets exist and simply ignore the question of access (= check as user 1).
I'm not suggesting to hard-wire user 1, but to allow impersonating an account for internal link checking, just as you currently allow it for error handling.
AFAICS this would result in strictly less errors, which could even improve security somewhat. Right now, all errors go to the watchdog log, and this could reveal the existence of links to targets that are not accessible to the user who looks at the log. OTOH it would open the possibility to guess and verify the existence of inaccessible targets, but this is a lesser evil IMO. Do you see any other potential security issues?
Comment #4
hass commentedI suggest you to disable checking of internal links. You configured a problematic non-default. The issues you are facing are well known.
If you can share a working patch I can review it.
As I already worked on D8, but it is incomplete and non-working it may be difficult to commit without running into regressions. But maybe the changes are not that big and could be easily adapted.
Comment #5
salvisHere's a first stab at this. It does what I need, but it may need some refining...
I came to the conclusion that it doesn't make much sense to offer a choice of users (other than user 1) and I just implemented a checkbox for now. A user selection could certainly be added if it adds any value.
What do you think?
Comment #6
salvisSorry, this is the one...
Comment #7
hass commentedThere are
linkchecker_impersonate_user()andlinkchecker_revert_user()functions in linkchecker. Have you seen them?Comment #8
salvisNo, I didn't see them, but of course it makes sense to use them. Here's an updated patch.
I'm not sure about two things though:
1. Is it enough to just go for
$GLOBALS['base_url']?2. Is it enough to just check
menu_get_item(substr($uri['path'], 1))?You're doing more, like differentiate on fragment, but I don't quite understand how it works, so I've ignored it.
Comment #9
quadrexdevD7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.
If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.
Thanks!