MW 1.35
SocialProfile 1.14 (fdafe9e) 23:59, 19 December 2021
Avatars don't work with private wikis using image_auth.php
I have verified that the web-server has read/write access to the folders and images, but still get the "Access denied - You are not allowed to execute the action you have requested." from the browser.. please advise
If you inspect the URL of the avatar, where does it point to? To image_auth.php? or directly to the images folder?
It points to: https://server/mywiki/img_auth.php/avatars/default_l.gif. File system permissions and ownership are not the issue. The situation is exactly as T163529 referenced above depicts.
This would be doable if the extension implements $wgImgAuthUrlPathMap and a custom file backend, which currently doesn't.
Cool. Maybe someday, but all I really wanted from SocialProfile was the avatar capability. No biggie. Maybe someone in the SocialProfile dev community will read your last comment and add the capability.. but it's no longer on my radar. Cheers!
Wait.. are you saying it could as simple as adding:
$wgImgAuthUrlPathMap['/avatars/'] = 'mwstore://mediawiki/images/avatars/';
to LocalSettings.php .. assuming SocialProfile is using a folder in the standard wiki upload directory? (which it is)
No, it won't work because a FileBackend must exist and be aware of that "images" path, which currently doesn't. Even if the default file backend is selected, it will probably fail the fileExists() check
This is a known issue (https://phabricator.wikimedia.org/T163529 ; also see https://phabricator.wikimedia.org/T88033) and there's a work-in-progress patch (which is outdated and not yet working nor being actively worked on) at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SocialProfile/+/444441 ; any and all contributions are more than welcome as img_auth.php related stuff is likely to be super low priority otherwise. It's certainly not something I'm testing, unfortunately, so I'm relying on the community for such patches! (SocialProfile and others social tools were written over 15 years ago and the wikis that initially ran the tools were 100% public; as such, it's not that hard to imagine why there'd be bugs with non-public setups.)
