Connection Not Secure

charles

this is what i get for viewing recent topics using firefox

Accalia Elementia

@charles looks like what happened is there's an image that's being loaded over http, rather than https.

If i had to guess that's being caused by a post in one of the topics.

try doing a hard refresh of the page and seeing if the warning goes away.

if it does then you cna pay attention to when the warning reappears to know when you ahve encountered the topic withthe problematic image.

if the warning still exists check other pages such as the homepage, making sure you do a complete page refresh on each.

If you still have issues.... well that's very bad and we'll want to look into it.

if it's just sporatic you can try installing the https everywhere browser plugin, which should seamlessly redirect most of those insecure requests to the secure version.

Accalia Elementia

Ah, that's what it is.

I was confused as to what could be causing it so fired up firefox to check. confirmed that /recent is currently displaying insecure content.

Using Dev tools in Chrome i've identified that it was loading these images over regular http instead of https:

http://i.imgur.com/oDYNb6S.png
http://i.imgur.com/9EC7UPE.png

.... anyway, the post with the images is: https://community.nodebb.org/topic/8218/change-nodebb-homepage-to-blocks/5

looks like this is caused by the "teaser" column loading the full post and having CSS styling applied to it to make the images not display and to prevent the content from spilling over the provided area.

qgp9

@accalia said:

.... darnit! how do i stop it oneboxing!?

This is a trick but just give a space before or after link contents.

 [ http://i.imgur.com/oDYNb6S.png](http://i.imgur.com/oDYNb6S.png)

http://i.imgur.com/oDYNb6S.png

Accalia Elementia

@qgp9 ah! thanks!

qgp9

@accalia

You are welcome

Actually this is highly tricky way. This works because nodebb-plugin-iframely is only working when a url and contents are exactly same without trim.

For my forum, I use of course my nodebb-plugin-magicblock

charles

@accalia said:

Ah, that's what it is.

I was confused as to what could be causing it so fired up firefox to check. confirmed that /recent is currently displaying insecure content.

Using Dev tools in Chrome i've identified that it was loading these images over regular http instead of https:

http://i.imgur.com/oDYNb6S.png
http://i.imgur.com/9EC7UPE.png

.... anyway, the post with the images is: https://community.nodebb.org/topic/8218/change-nodebb-homepage-to-blocks/5

looks like this is caused by the "teaser" column loading the full post and having CSS styling applied to it to make the images not display and to prevent the content from spilling over the provided area.

Thanks for testing on your end! Glad it's not only me. Sounds like a bug that will need to be fixed in the next release.

Accalia Elementia

@charles said:

Sounds like a bug that will need to be fixed in the next release.

i'm not sure how it could be fixed to be honest. These are user generated links.

yes the teaser could be collapsed to not load the images on /recent but that won't stop the warning from occurring when visiting the topic itself.

In this case a user posted content that included links to imgur that were over http these links were automatically turned into images, which is easy to do. What's harder to do and probably more trouble than it's worth is figuring out that that imgur serves the same content over http and https and upgrade the links to https.

one could upgrade all image links to https, but then you have the issue of sites that don't exist in both http and https.

And then there's the issue of altering user provided content. That's always a touchy subject for some forum users, and something that should be considered carefully when implemented.

One could also take the approach that Discourse did where by default the forum downloads remote images and serves them up from the forum itself. This does neatly bypass the issue of the missing HTTPS connection, however it did land several installs of discourse into legal hot water regarding rehosting images without proper attribution, so there's that downside... not to mention the additional storage required for the cached images.

You're welcome to open an issue on github for this if you want to, but i would not expect it to gain much traction given the level of thought and effort that would be required to fix this issue, and given that plugins like the aforementioned https everywhere exist and are easy to install.

Security is important, yes but HTTPS is far from universal yet and so there aren't any simple answers that i can think of to user provided content.

Maybe someone smarter than I can come up with something though, so there's no harm in asking.

Jared14406

This post is deleted!

yariplus

camo is probably the best solution for serving images. I'm not really an expert on it or how it works, but it seems to be popular.
https://community.nodebb.org/topic/7927/install-camo-for-nodebb-plugin-iframely

qgp9

@accalia

Imgur support boths of https and http for same image. Actually best way to put an image is an using of //i.imgur.com/oDYNb6S.png without http or https.
Like the imgur, if image sites which support both protocols are listed, a simple filtering plugin will not be difficult.
After those, an solid solution will be a proxy by nodeBB. But I don't don't think that NodeBB need this feature. Already there are many ( with anticipation ) independent standalone solutions. So I would say, it will be really good to NodeBB if somebody check and research open source solutions, or free services.

qgp9

OR, just block them and give links/messages

rod

How about a plugin like nodebb-plugin-secure-images ?

charles

@qgp9 said:

@accalia

Imgur support boths of https and http for same image. Actually best way to put an image is an using of //i.imgur.com/oDYNb6S.png without http or https.

I agree with that suggestion as google did the same several years ago.

nodebb can simply strip (or have an option to turn off) http and https and allow urls to just have // www. example. com is better than forcing.

Accalia Elementia

@charles said:

// www. example. com is better than forcing.

while i agree with this in principle it won't solve the issue of www.myrandomblogaboutsocks.com only serving content over http. if you try to link http://www.myrandomblogaboutsocks.com/public/images/uploads/mine/some/path/image0457239.png as //www.myrandomblogaboutsocks.com/public/images/uploads/mine/some/path/image0457239.png and you are currently on https, what you'll get is a broken image.

which is not something users expect.

i think ultimately the best solution for most forums is to have a whitelist of image hosts to use that support https, inline images via //domain.example.com/path and just leave all other images as links.

it's not the prettiest nor the best user experience, but i think it strikes a nice balance between ease of implementation, ease of use, and ease of understanding for non technical people.

qgp9

@accalia said:

www.myrandomblogaboutsocks.com

Frankly, I clicked this link. ( even 4 times to be sure )

I agree with you. That will be a most transparent way.

And advanced users can try image proxy ( camo ).

Accalia Elementia

@qgp9 said:

Frankly, I clicked this link

hmm.... i'm now tempted to buy the domain name and put a markov chain generated blog there....

maybe if i remember after i finish getting version 3.0 of SockBot out the door.

charles

@accalia said:

@charles said:

// www. example. com is better than forcing.

while i agree with this in principle it won't solve the issue of www.myrandomblogaboutsocks.com only serving content over http. if you try to link http://www.myrandomblogaboutsocks.com/public/images/uploads/mine/some/path/image0457239.png as //www.myrandomblogaboutsocks.com/public/images/uploads/mine/some/path/image0457239.png and you are currently on https, what you'll get is a broken image.

which is not something users expect.

i think ultimately the best solution for most forums is to have a whitelist of image hosts to use that support https, inline images via //domain.example.com/path and just leave all other images as links.

it's not the prettiest nor the best user experience, but i think it strikes a nice balance between ease of implementation, ease of use, and ease of understanding for non technical people.

the result would be:
if a visitor visits http site and the image is using // then it will serve the image with http:// url
if a visitor visits https site and the image is using // then it will serve the image with https:// url

so using url path without http or https is the advantage.

am I understanding it incorrectly?

Accalia Elementia

@charles said:

if a visitor visits https site and the image is using // then it will serve the image with https:// url

which is a problem if the webserver does not respond to https requests

if the server supports http and https then the // prefix is correct but if the server only supports http then the // prefix is broken

that was my point. you can't know ahead of time if a random webserver supports both http and https, and https is not yet ubiquitus enough to assume there is https support (but hopefully initiatives such as letsencrypt fix that soon)

charles

@accalia once letsencrypt make it easier it should get more people to use ssl. I'm guessing most large sites have ssl so using // should be non issue.