When logged in (OIDC?), connection becomes marked insecure

voc0der commented 3 months ago

Environment

Docker / debian/unstable

Version

0.15.0

Describe the problem

Have 2 different homarr instances, similar setup, but the same problem.

If I'm not logged in, the connection is green padlock secure. If I log in (OIDC is my provider), then it's yellow. Everything important is being encrypted but it's loading http://i0.wp.com/null and getting a bad request (400) in the browser console > network logs

I'm not sure if this URL goes somewhere my adblock won't let it, but either way, it should not be going over port 80 as it causes the browser to flag the entire request as insecure.

Logs

Nothing special here, I think this is a generic bug.

Exporting hostname...
Migrating database...
yarn run v1.22.19
$ ts-node ./migrate.ts
Done in 1.11s.
Starting production server...
Listening on port 7575 url: http://x:7575
netsamurai@dmz-server:~$

Context

Please tick the boxes

[X] I confirm that I attached the proper logs
[X] I've read the docs
[X] I've checked for duplicate issues
[X] I've tried to debug myself

SeDemal commented 3 months ago

i0.wp.com seems to be WordPress's caching server for images. My guess is that one of the images on your dashboard is provided through them. We don't use it in our code so I'm not sure where you're making this request.

voc0der commented 3 months ago

Isn't it kind of weird that when I log out the request is not made if I'm not logged in though? For me, the dashboard is exactly the same regardless of logged in / out in both instances.

voc0der commented 3 months ago

Is it possible this is related to gravatar? https://buddypress.org/support/topic/what-is-i0-wp-com/ . I currently do not use it at all in my instance, but it does appear in the source code when logged in. Maybe because I am not a user of gravatar, this happens. And maybe because you are, it can't happen because your email is associated with a different link probably.

SeDemal commented 2 months ago

Sorry I've only took time for this just now. You are right, when investigating another problem with gravatar I've seen that it returns to this page when the email is invalid. the ?d=null should have been a ?d=404. I'll be making a PR to rectify that along fixing the avatar with broken image.

voc0der commented 2 months ago

Is it possible to not make any request at all to gravatar (optionally), as that is helping them get data? I'm not sure why you'd want to give someone your email and whatever metadata (like http_referrer) every time you simply want to use an avatar.

Otherwise, Thank you! Currently the 'broken image' is just the first initial of your username.

SeDemal commented 2 months ago

Actually the broken image is just me chasing my own tail, it's a dev environment only problem... (it would show a broken image instead of the 2 letters which we want to show if no real image is pulled) I'm adding libravatar as the default instead (because of the open-source nature, and that they proxy gravatar on top of their own data). As far as I'm aware, they don't collect data from simple image requests. So unless you willingly register on their services, not much if at all for them to get (or is there something I may be unaware of?).

voc0der commented 1 month ago

I can confirm that the connection is marked secure, however, I am still concerned by the decision to not protect user data as a default. Understand it's my choice in the end to use this, but just wondering why this is so important to keep hard coded as a feature. Seeing the request to whatever domain with my email in the payload is pointless data theft. And no, turning it into a SHA-256 Hex hash they can decode doesn't help.

Hope in the next versions there's more flags regarding any data leaking features.

SeDemal commented 1 month ago

This was actually just a quick fix for the current version. Next major version will allow for user uploaded profile icon.

ajnart / homarr