Friendica: Red Circle Slash Image Everywhere

[miqrogroove]

Randomly, but particularly after emptying browser cache, if I go to my network feed, or even someone's profile status page, any images they posted with friends-only permissions is replaced by a red circle. When I go to their Photos page, it doesn't show any of their friends-only photos to me. The problem goes away just as randomly, but is sometimes persistent. Frustrating problem overall.

[miqrogroove]

Just saw this on a contact page:

Network type: Friendica
Last update: Fri, 22 Jun 2018, 2:00 AM (Update was not successful)

[miqrogroove]

Clicked the Update Now option in the menu. Refreshed the page and got this

Network type: Friendica
Last update: Fri, 22 Jun 2018, 2:16 PM (Update was not successful)

🤨

[miqrogroove]

Frequently seeing the message "Skipping probably dead contact" in my debug log. Nothing else looks bad in there. No message in the debug log about unsuccessful contact updates.

[miqrogroove]

Switch to a different device, it looks like the feed photos are cached in there, so no red circles. But then I go to the Photos page on the user profile and most of their photos don't even show up now.

[miqrogroove]

In the database, I can see where the photos are still in the photo table. The gid field shows the correct group number. The group_member table shows a contact-id value that points to a contact table entry that has my name on it. So I can see that I'm a member of that user's friends group. But something has broken my ability to see their photos on the front end.

[miqrogroove]

Tried several more things. Restoring the database from a Tuesday backup was the only thing that worked so far. 😳

[miqrogroove]

Saw this now while still troubleshooting.

[22-Jun-2018 20:23:44 UTC] PHP Fatal error: Uncaught TypeError: Argument 4 passed to get_responses() must be of the type array, boolean given, called in /mod/photos.php on line 1602 and defined in /include/conversation.php:1423
Stack trace:

0 /mod/photos.php(1602): get_responses(Array, Array, '', false)

1 /index.php(401): photos_content(Object(FriendicaApp))

2 {main}

thrown in /include/conversation.php on line 1423

[MrPetovan]

This has been reported (twice!) in #5257

[miqrogroove]

Well I'm glad it's not just me then. What the heck did we break?

[MrPetovan]

Historians will judge.

[miqrogroove]

On photos.php line 1346 or so,

Item::selectFirstForUser(6, [], ['id' => '764']);

The return value is false.

[miqrogroove]

Something is wrong with this part of the SQL. Still can't put my finger on it.

WHERE (`item`.`id` = 764) AND `item`.`visible` AND NOT `item`.`deleted` AND NOT `item`.`moderated` AND (`user-item`.`hidden` IS NULL OR NOT `user-item`.`hidden`)  LIMIT 1

[MrPetovan]

How do know it’s this part causing the error?

[miqrogroove]

One of the dozens of conditions among the JOIN and WHERE parts is that "AND item.visible" which is false, at least in this case.

[miqrogroove]

in function selectFirst() we have

            $row = self::fetch($result);
            dba::close($result);
            return $row;

But if $result is empty then what does dba::fetch() return? I believe it just throws false. And there are so many unchecked return values being passed around, it's hard to know where the bug is exactly.

[MrPetovan]

Welcome to @annando’s personal theme park! 🎡🎢🎠

[MrPetovan]

The answer is false. Boolean are passed as is.

[miqrogroove]

I'm going to take an educated guess and say that THIS

https://github.com/friendica/friendica/commit/baf316e89808b1480f1fa69916cc2b60c343993b#diff-043fd70296cbf595b3caed1b2dc79248

just ain't right!

[miqrogroove]

git reset --hard b53e74d989f3be198c32ff6c28a7118d774ea204

This resolves the fatal error. I still can't find all the photos but... there is hope.

[miqrogroove]

Just starting to make some progress on the missing photos. In mod/photos.php we have for example:

        WHERE `uid` = 6 AND `album` != 'Contact Photos' AND `album` != 'Contact Photos'
         AND allow_cid = ''
             AND allow_gid = ''
             AND deny_cid  = ''
             AND deny_gid  = ''

On my site, this condition only returns 3 records 😢

The actual source is:

    $r = q("SELECT `resource-id`, ANY_VALUE(`id`) AS `id`, ANY_VALUE(`filename`) AS `filename`,
        ANY_VALUE(`type`) AS `type`, ANY_VALUE(`album`) AS `album`, max(`scale`) AS `scale`,
        ANY_VALUE(`created`) AS `created` FROM `photo`
        WHERE `uid` = %d AND `album` != '%s' AND `album` != '%s'
        $sql_extra GROUP BY `resource-id` ORDER BY `created` DESC LIMIT %d , %d",

[miqrogroove]

Now I've traced it back to this line:

    if (remote_user() && !$visitor) {

With my current database, remote_user() returns false. When that fails its test, it flows into permissions_sql() with the $groups param set to an empty array. permissions_sql() again checks remote_user() and then returns the anonymous permissions condition.

[miqrogroove]

According to the remote_user() block of boot.php, my $_SESSION has no mention of visitor_id at all.

[miqrogroove]

I don't know anything about DFRN. This is getting depressing. dfrn_poll_init() is repeatedly called with 'type' => 'profile' and a long hex value for 'sec'. That function does absolutely nothing in that situation.

[MrPetovan]

DFRN is the protocol used to communicate between Friendica instances.

According to the remote_user() block of boot.php, my $_SESSION has no mention of visitor_id at all.

Have you pulled develop less than 2 days ago? @rabuzarus added a couple of visitor_id declarations. See #5253

[miqrogroove]

I've rolled it backward and forward. The only thing that helps is the 4-day-old database. I have no idea what's in the DB that could have changed to break this, or why it's so fragile in the first place.

[MrPetovan]

You and me both, unfortunately.

[annando]

Concerning DFRN: There is a reason why I rewrote the transport layer and why I'm looking forward to this "OpenWebAuth".

Concerning the invisible item: I haven't checked, but possibly every photo upload creates an item entry that is invisible under certain circumstances.

[miqrogroove]

I couldn't find any problem with the missing photos. They are gone as expected for authentication failure. So there are two problems now. One is the bad query conditions and results handling in class Item. The other is a breakdown in DFRN somewhere.

[annando]

The item class isn't the problem here. It's just that invisible item. I will have a look at mod/photos.php this weekend, but will be away today.

[miqrogroove]

The latest pull fixes the other ticket.

I'm still unable to authenticate to friend profiles on the same site.

[miqrogroove]

WORKAROUND

I solved this by process of elimination. Note these symptoms:

1. No problems identified in the photo code.
2. No changes in any of the photo, item, or similar tables.
3. No "x welcomes y" message displayed on front end.
4. Able to trace repeated authentication failures in DFRN.

Steps to restore previous state:

1. Search the database for my contact record related to the user. It is one of the results in SELECT * FROM `contact` WHERE nick='my nickname here'
2. As explained in earlier posts, the other user's id was 6, so actually SELECT * FROM `contact` WHERE nick='my nickname here' AND uid = 6
3. Note any differences from a working backup. In this case, the backup shows id=403 and NULL for contact.pubkey whereas the live database had a public key saved in several hundred characters.
4. Restore the working value with UPDATE `contact` SET `pubkey` = NULL WHERE id = 403
5. [edit] Navigate away from any problematic profile page. Clicking the Reload button only may not work.

I am immediately seeing normal behavior restored after those exact steps.

[MrPetovan]

Thank you for the detailed follow-up!

[miqrogroove]

The contact page still shows "Update was not successful". Not sure what that means, but it doesn't bother the photos.

[miqrogroove]

There seems to be a related issue with new sessions and/or caching. I switched to the Edge browser just now, and got the Red Circle Slash again on the network feed. As soon as I went to the profile and the Photos page, everything cleared up again.

[miqrogroove]

There are also situations where I log in, can see a friend's photo in the network feed, but if I click on the photo to zoom in, it just shows me the red circle slash. I then have to click the profile link and try to zoom the photo on the friend's feed to see the image. It's as if, until I can see the 'x welcomes y' message, it's not going to check permissions and not going to show me the photos.

[tobiasd]

Red circle replacement images mean, that you as a viewer, have not the right to see the picture. This happens when your browser session is not authenticated against the profile of your contact via RemoteAuth, some browser addons might block the process.

[miqrogroove]

My browsers have no addons currently.

[tobiasd]

:-) 3rd party cookies need to be working as well IIRC to store the session of the other node.

[miqrogroove]

I have 3rd party cookies disabled in Chrome for Windows. Yet, I'm getting the same problem in other browsers. When I first log in and look at the network feed, it's not doing this RemoteAuth or whatever is supposed to happen, and I can't see all the photos until I visit the owner's profile.

[tobiasd]

When you visit the owners profile (via a MagicLink, which results in the bubble info XYZ welcomes ZYX) the RemoteAuth was performed. When you request non-public materials from their node the Auth is checked and the materials eventually send to you.

There is a setting to "Not embed images in private postings" (back translated from DE translation) which can cause this forced visit on the other persons profile. RemoteAuth should still work in the background automatically, taking some time, but that seems not to work for you for some reason.

[miqrogroove]

I've got that setting disabled. What it says is:

Don't embed private images in posts
Don't replace locally-hosted private photos in posts with an embedded copy of the image. This means that contacts who receive posts containing private photos will have to authenticate and load each image, which may take a while.

To me that means, if I turn it on then private images will be removed from the feed.

I tried turning it on now, and there was no difference at all when I logged in again.

[miqrogroove]

For the sake of testing, I also tried to disable the Block Public setting. Again, no change with the Red Circle Slash everywhere a friends-only image should be in the feed.

[miqrogroove]

I'm starting to suspect the remaining issue is related to the fact that public and private images in the feed have different URL formats. One is like /photo/guid and the other is like redir/id?f=1&url=https...

If I can find the exact steps to reproduce that second issue, I will open a new ticket for it.

[tobiasd]

The redir is the RemoteAuth URL, so your browser loads the image from the redir link, gets verified at the remote end and you can view the image.

[miqrogroove]

Public posts don't have the redir. So if a user changes the photo permissions, we still have a public post with no redir that only shows a red circle slash.

[tobiasd]

Why would someone post a private photo in a public posting? I don't see the usecase for this.

[miqrogroove]

Are you saying my users are expected to never change photo permissions?

[MrPetovan]

Why would someone post a private photo in a public posting? I don't see the usecase for this.

It isn't the point, if it's possible, then we should either account for it or prevent it altogether. Pick your poison.

[tobiasd]

No, I misunderstood what you were saying.

[miqrogroove]

This problem just occurred for the second time. A friend uploaded new photos, I went to look at them, and I could only see the public photos and none of the friends-only photos. I ran the discovered workaround again to fix it:

UPDATE `contact` SET `pubkey` = NULL WHERE id = 403

This is very tiresome. If I can't even see my friends' photos on my own website without screwing with the database on a regular basis, then it may be too broken for production use.

[miqrogroove]

Same problem again today. I am unable to see photos that friends marked with friends-only permissions.

In phpMyAdmin, I can see that, yet again, the pubkey field has been populated with a new value in contact record id=403.

[miqrogroove]

I have one more bit of information to add. After running the SET pubkey = NULL query, refreshing the photos page will not fix the problem. I have to navigate away from the friend, and go to the friend's profile anew to trigger the authentication.

[miqrogroove]

Next time this happens, I would also like to test federated profiles. For example, when I visit Friendica Support now it shows me as a Visitor with my profile photo and links back to my own site. I'm wondering if this behavior is affected by the same bug.

[miqrogroove]

I'm seeing this bug again right now. Instead of using my workaround, I tried visiting a few other sites and profiles. Guest/Visitor authentication to other sites is not affected. Authentication to my other friends on my own sites is not affected.

Based on this new info, I think the bug is either specific to this one friend, or when triggered it only corrupts one contact.

Now I'm desperately in need of a solution or at least some way to trace this bug to locate the problem.

[miqrogroove]

Going to hack on this a bit more today. Is anyone still following this issue? If not I'll start a new one when I have something specific.

[annando]

I'm currently focussing on other topics, I must confess.

[miqrogroove]

This may have been fixed in a recent pull, July-ish. I will watch out for similar problems in the future.

[miqrogroove]

I just realized my friend is now unable to see any of my private photos.

[miqrogroove]

False alarm this time. It cleared up again upon visiting the profile page to authenticate.

This system remains horribly unreliable, but I am unable to reproduce any persistent errors now.

[miqrogroove]

Just going to leave this open now. I'm still getting reports from users that they can't see anything except red circles on my site. It's getting to the point where I've done all that I can to troubleshoot and I will have to abandon this software. 😕

[miqrogroove]

But before I delete anything, I just checked the admin console and I'm seeing my own error message from #5660 again. If these are the same issues I wonder if I can take care of it with a cron script.

[miqrogroove]

It looks like we have yet another bug here. After re-patching the .well-known incompatibility again, I phoned a user who could see the red circle and we narrowed the problem down to a single photo. This time, it looks like the photo object posted with no effective permissions, while the status text did have correct permissions.

[miqrogroove]

I confirmed this is reproducible in the 2018-08-RC. Going to do more testing on the RC, upgrade, and try to confirm the bug in 2018-09.

[miqrogroove]

Please see #5805

[deantownsley]

I seem to be having problems very closely related to this as of the 2018.09 update. I've tried the update twice and both times while all old embedded photos in posts seem fine, any new ones somewhat randomly show the dreaded red slash. This is on a mostly-private site. I've even tracked problems to many of the same spots mentioned in this thread. (The session stuff and the visitor authentication stuff and the pubkey issues.)

My problem appears related to two changes as of 2018.09. One is that the embedded photos "src=" are now redirects rather than inlined data, and also local users are treated as visitors (i.e. the old code seemed to assume a user is either local or visitor, but now it appears to be possible to be both).

I haven't gone through the whole thread, so I may not be in quite the same boat. I'll keep reading. I just wanted to say something since I just tried the 2018.09 update for the second time and had to revert again. Last time I tried it I came to the conclusion that the permissions tables were completely messed up, so I thought it might have been an update issue. I have kept the updated database to inspect but haven't been able to investigate too much yet.

This is a production site so I will need to set up something for testing.

[miqrogroove]

I just noticed there was a patch #6159. I will test it this week.

[miqrogroove]

Patch #6159 works for me.

@deantownsley Have you checked the admin page to see if there are any new health check errors after upgrading to 2018.09? Have you also applied the new patch?

[deantownsley]

The admin page just showed the config file change (move to config/local.ini.php). No other errors.

6159 doesn't seem related. The permissions are as expected on the images I'm having trouble with. My problem is more like the original issue in the thread.

It appearance of the red-circle-slash is very intermittent. The best way to reproduce I have found is:

1. update to 2018.09
2. post a few posts with pictures uploaded via the modal dialog that are only visible to one other user.
3. clear cache and cookies and close the browser
4. open browser and log in as the viewing user (goes to network tab) and pics appear correctly (not sure if that's 100%)
5. go to another contact's page (not the one that posted the pics)
6. return to the network tab. Some of the pics are red-circle-slash.

At that point the only thing that makes the pics come back is to visit the page of the user that posted the pics, getting the "XYZ welcomes ZYX" message. The pics then appear in the network and on the status page as normal.

I'm also seeing two other problems:

1. the pre-update posts in the status of the posting user above aren't visible to the viewing user, despite the viewing user having permission to see them. (pre-update posts on the "viewing" user's status are visible to the other user (i.e. the other way works))
2. I use the mailstream plugin and in 2018.09 it appears to never get the pic to include in the email. (always red-circle-slash)

Note that I'm also having the issue with having to clear the pubkey manually from the database sometimes to get a user's status to be visible. I'm unsure if the inability to see pre-update posts for this one user is related to that. Previously I had cleared all the orphaned pubkey entries before the update, but this time I didn't notice it had reappeared until after the update.

Sorry this is all rather confusing. I tried updating to the current develop and rc branches, but they didn't work at all, which I assume is not surprising. I'm happy to try a specific commit if it would help.

I'm still not sure what to do. I feel like the only way forward is to set up a stand-alone test site to try to figure this out.

[miqrogroove]

That pubkey issue, for me, was a bug we tried to address in #5660 . I think you will need to do more troubleshooting if the symptoms are different.

[deantownsley]

Thanks for the tips. In regard to #5660, I don't have any .htaccess files in my .well-known directory, or any unusual rules in my apache config, and I'm using the default friendica .htaccess files. I do use letsencrypt but don't seem to have had any trouble.

It seems like the reappearance of the orphan pubkey is some issue in the older version (2018.05). I had intended to clear these before update but forgot before trying the update again yesterday.

I should also say, that the above procedure is what is reproducible. When I initially tried the update and started using it, the problem manifest as follows -- when I had several pics in my feed from different contacts, some random subset of them would be red-circle-slash. It was as if it could only authenticate to a few of the contacts at a time. But this was so tangled up with the pubkey issue (which I didn't fully understand at the time) that I wasn't able to sort it out clearly.

[deantownsley]

Well, I was able to reproduce this in a fresh install of the current master branch (2018.09). After installation, I created 3 users, 2 of whom are the first user's contacts. Set them all to have default post permissions of friends-only. Then as each of the three users, post a simple status post with a picture uploaded via the modal dialog. Then if I clear cache and login as the first user (who should be able to see all three posts and pics), on network page one of the two pics posted by the contacts is a red-circle-slash. I can get both pics to load by clicking on them (effectively forcing authentication to both contacts).

I can't find any errors reported in the server logs or anything (like a php problem or such). Next step is to start poking around and adding log info to figure out what is going on...

[deantownsley]

I'm not sure I 100% understand it, but after putting in some logging and such, i have some idea of what is going on.

It appears that although mod/redir.php:redir_init() handles the case that a single session can be simultaneously authenticated as multiple contacts via the 'remote' array in the session, the include/security.php:permissions_sql() function that is called from mod/photo.php:photo_init() appears to only check permissions using the remote_user() id, which is a single contact. It doesn't use the 'remote' array. I think this means that if (private) photos from multiple different contacts who are on the same server are loaded on the same page, all but one of them will show up as red-circle-slash, at least on the first try. I think the only reason that individually loading each photo and authenticating works is because once the photo is successfully loaded, it is in cache and is not retrieved again. The cacheing info is set intelligently, so that a failure to load is retried, but a successful loading is cached.

I'm also a little unsure about the populating of the 'remote' array, but I didn't investigate that as much.

My inclination is to implement an iteration through the session 'remote' array in the permissions_sql() function to find the right contact id that is supposed to be used for checking permission, instead of just trying the single one indicated by the return value of remote_user(). I'll try that next.

On a related tangent... While going through this, it occurred to me that there is actually a site setting for whether or not private images are encoded directly into posts. I looked, and "Don't embed private images in posts" is not checked. It would seem that setting is no longer being respected for some reason, since in my tests the posts don't have embedded images, they have redirects. I'll look into that separately and maybe file another issue for it.

[miqrogroove]

Sounds like progress to me. I ran out of patience before I even got the authentication working. I hope the remaining bugs with the photos can be fixed now.

[deantownsley]

I've looked more into when included images are embedded in posts (i.e. when the src= points to a data blob instead of a url). This behavior has changed significantly in 2018.09. It appears that embedding only happens if the post is shipped off-site. (I did test that it does happen for an off-site recipient.) If both the poster and recipient are on the same server, only the version of the content with the src=url is used. I'm concerned that this means that images in posts behave very differently for same-server contacts vs. off-server contacts. Specifically if there is a post with a picture in it for which the picture is later deleted, if the recipient is off-server they will still have the embedded image, but for recipients on the same server, the image in the post will no longer work. This appears to defeat what I have always thought was one of the major intentions of the embed-images site-level setting.

This appears to be related to the improved efficiency in the item table. Previously the user authoring the post had an item in the item table with the images included as src=url, but each recipient had an item with an embedded image. It appears that now there is only one copy of the post content in the item-content table (I appreciate that this is a huge space saver). However, it appears that instead of opting to use the version of the post with the embedded image everywhere (which I would argue is consistent with the site-level setting for embedding images in posts), the content version with the src=url image was used instead.

I'll have to do a bit more homework to fix this properly, and it would be nice to hear from any who were involved in the item table work.

I also noticed something that I wasn't expecting... in 2018.09, the post body in the item-content table is re-written every time the post is loaded by a different user. For the posting user, the image has the bare url of the image, but for other users the url is converted into a redirect. So the content of the item in the item-content table is different depending on which user last viewed the post. I don't know about anyone else, but this behavior makes me nervous about race conditions and such.

[MrPetovan]

Paging @annando for the finer points of the item table migration.

[annando]

@deantownsley Are you sure that this is written into the database table?

[deantownsley]

@annando I double-checked... I should have been a bit more careful. The "body" column doesn't change (the BBcode version), the "rendered-html" does.

Alice and Bob have both posted a post with a picture in it. After Bob loads his network page, the rendered-html has a redirect for alice's picture but a normal src=url link for his. After alice loads her network page, it is swapped. I'm using "select * from item-content" to look at the database.

Maybe this is okay since the bbcode version doesn't change. It still seems a little scary for a large number of users and posts since those rendered-html entries will be constantly changing.

[annando]

This shouldn't happen as well.

[deantownsley]

Sorry to be silent on this issue for so long. I still have the same problem even with current releases. i.e. private pictures don't work for users on the same server as the posting user. As mentioned before, one reason for this is the pictures not being embedded in the post, which they previously were for the receiving user.

My proposed fix is to embed private photos during the initial preparation of the item rather than during delivery. I realise this is a bit of a far-reaching change since it means that now every item with private pictures will have them embedded, but I think this follows the spirit of the "(do/don't) embed private photos" setting in the configuration. i.e. someone posting can't later break the post by deleting the original image. Site admins that want the other behavior, in which images are always img src= links instead of embedded data can always just change that site setting.

I will follow this message up with a pull request referencing this issue.

Note that this is not really a full fix for the initial issue. I think the underlying authentication issues that prevents private images from multiple local contacts loading on the same page are still broken.

[miqrogroove]

I am still hearing user complaints about this bug 😥

[deantownsley]

I think I can say exactly where the problem is, I just haven't had the chance to implement and test a fix. The function getPermissionsSQLByUserId() in src/Util/Security.php needs to process the "remotes" array rather than just the $remote_user variable. This is done in other functions, so there are examples, I just haven't ported it here quite yet.

[deantownsley]

I just submitted a pull request that I think fixes this partially. The code providing the image will now check all the authentications in the "remote" array in the session. However, it appears that the bare image request doesn't trigger an authentication.

I'll give a short description of the current behavior I'm seeing with #7237 applied: When loading a feed with posts from multiple users containing private images (all users on the same server), a "fresh" session will show red-circle-slash for the images. If I click on some links to visit the other user's pages and trigger the "b welcomes a" message, then the images from "b" will load. I can now get images from more than one user, e.g. "b" and "c" to load. Before #7237, it would switch between having b's images appear or c's images appear depending on whose authentication had happened most recently.

I think this may be tied up with the HTTP auth mentioned by @annando in my previous proposed fix #7138.

I thought way back when I first looked at this, the img src= entries were redirects for images not owned by the user loading the feed. While that did lead to the item being changed in the database every time it was loaded, I think the redir did trigger the authentication, but I'm not sure I'm remembering clearly.

So still a bit more work to do unfortunately.

[miqrogroove]

I just submitted a pull request that I think fixes this partially. The code providing the image will now check all the authentications in the "remote" array in the session.

While I don't understand most of the API here, your PR still checks at most only one value of $cid. This value may be different than $remote_user, but if your intention is to check getIdsByContactId() more than once per call, it will need to be inside of a loop.

[miqrogroove]

I can now get images from more than one user, e.g. "b" and "c" to load.

So it works but only if you visit all the profiles before the feed page?

[deantownsley]

The call to Group::getIdsByContactId() is to get the list of groups that the contact we've found is in. There is no need to call that more than once. The $cid is the number of the entry in the contact table. This number is different for each different combination of contact and profile. i.e. Alice has a different cid as Bob's contact and as Cary's contact. The thing that checks multiple authenticated contacts is the iteration through the remote session array. If Alice has been authenticated to both Bob and Cary, that is two separate entries in the $remote[] session array. So if if Alice is trying to retrieve a photo owned by Bob, we look for an entry in the $remote[] array where Bob is the "uid". The corresponding "cid" in that entry in the remotes array is the cid of Alice as Bob's contact. The code then proceeds to construct a query string that will check whether that contact is allowed to view the photo (i.e. is allowed individually or a member of an allowed group).

Hopefully that clarifies.

[deantownsley]

Yes, it currently works if you "pre-authenticate" to each user that has a private picture showing on your feed page. That used to only work for one at a time. Now you should be able to "accumulate" the authentications. So still broken. Only a partial fix.

There is a separate bug that, for some reason, the authentication is not being done for bare image retrievals. The current posting code does add the zrl to the img src= URL for private images, so the authentication _should_ take place. But it doesn't. The relevant spot is protected by an if !localuser, which I think is wrong now that one can be both a local and remote user, but when I remove that protection it breaks in a bunch of other ways. I haven't figured out how to make it authenticate when an image retrieval comes in with a zrl argument. Sorry I'm being vague here. I just haven't figured it out yet.

[MrPetovan]

The general condition to check is a user is authenticated, whether local or remote is local_user() || remote_user(), maybe it would help with this separate bug.

[deantownsley]

Just to follow up here... I ended up not trying to change the code that uses the zrl (which I mentioned is protected by the if !localuser, and seemingly rightly so). Instead, as mentioned in the pull request, I tried to just make bare image loads authenticate the same way that an image container page does. That seemed like a fix that would cover more cases.

Currently this seems to work for me. A "cold" (no session) load of a feed page with posts from multiple other users on the same server that contain private images will now load all images.

[MrPetovan]

(Hopefully) Fixed by #7305

[miqrogroove]

User testing this reported there are no more red circles, but none of my private photos are visible at all.

[miqrogroove]

Also, none of my private posts are showing up. Seems to be an unrelated critical permissions failure.

[MrPetovan]

Thanks for the report!

[deantownsley]

That sounds like it could be the issue with the extra key appearing in the contacts database. I think this was mentioned earlier in this thread. (though I don't see it right off, it's a long thread!) As I understand it, each contact entry should contain either a private or public key for the connection itself (separate from the key of the remote user), but not both. So far for me, fixing that has always required me to manually change the contact table to remove the extra key. I haven't seen this issue on my test instance, so I thought it had been fixed. However, even if the code that adds the spurious key is fixed, if the key is there it may still cause authentication to fail until it is cleaned out. Hope that helps.

[MrPetovan]

Paging @annando to comment on this hypothesis as I'm out of my depth.

[miqrogroove]

I only troubleshooted as far as check the admin page for notices, creating one new user, added as a mutual friend. Same result. I've deleted my Friendica node and will not test further. Good luck.

[MrPetovan]

Thanks for all your contributions!

[deantownsley]

Yes, I'll just say that if it was the problem I was thinking of, your procedure should have worked. Sorry it didn't work out. Thanks for trying.