Use https

Question

Use https

Closed this issue 7 years ago · 32 comments

I am embedding pages from cppreference in an iframe from a web app (the jupyter notebook), which fetches the resources from cppreference based on some tag file.

The problem is that when the connection to jupyter is https, the CORS setting disallow loading content from an insecure source. Would it be possible for cppreference to be served over https?

povilas commented 7 years ago

huh? :)

SylvainCorlay commented 7 years ago

woot!

Answer 1 · 2017-09-09T15:20:01.000Z

Could you ask this question on http://en.cppreference.com/w/Talk:Main_Page? The hosting of the website is handled by Nate Kohl, I don't think he monitors this repository.

Answer 2 · 2017-09-09T15:36:48.000Z

Thanks! Closing this issue.

Answer 3 · 2017-09-09T16:58:51.000Z

It does not seem that I have permission to contribute to this page on the wiki.

cc @natekohl

Answer 4 · 2017-09-10T07:12:05.000Z

I've unprotected the page temporarily, you can edit now. Sorry for not checking earlier.

Answer 5 · 2017-09-10T09:02:23.000Z

Thanks. I could edit the comments page! 👍

Answer 6 · 2018-03-23T12:59:14.000Z

@SylvainCorlay Seems like nothing has been done about serving cppreference over https huh? Did you find any other fix ? I am running jupyterhub over https for my uni.

Answer 7 · 2018-03-27T10:28:00.000Z

Hey @sigurdurb sorry for the late reply.

There has been some discussion with @natekohl and @yuvipanda about how to fix this and configure the old version of mediawiki used by cppreference, but no solution to the issue yet unfortunately.

Regarding your use at your Uni, are you using xeus-cling for C++?

Answer 8 · 2018-03-27T11:02:33.000Z

Would upgrading MediaWiki to newer version make https support easier? Upgrading will need code changes to the skins though, I have most of that done some time ago, but it's not tested properly yet.

Answer 9 · 2018-03-27T11:34:23.000Z

@SylvainCorlay Yes, I have it with xeus-cling. Right now I am just testing it but maybe next fall we will start using it with Jupyterhub.

Answer 10 · 2018-03-27T13:25:50.000Z

@SylvainCorlay Yes, I have it with xeus-cling. Right now I am just testing it but maybe next fall we will start using it with Jupyterhub.

Awesome! If you have any question on xeus-cling, don't hesitate to hop on our permanent chat. https://gitter.im/QuantStack/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge

Answer 11 · 2018-03-27T14:12:08.000Z

@povilas -- I suspect upgrading MediaWiki would help make https easier, but I'm not entirely sure. I think you're right about needing code changes to the skins, though -- I tried upgrading a few weeks ago and everything kinda broke. :P Do you happen to know what kind of code changes the skins would need?

…

On Tue, Mar 27, 2018 at 9:25 AM Sylvain Corlay ***@***.***> wrote: @SylvainCorlay <https://github.com/SylvainCorlay> Yes, I have it with xeus-cling. Right now I am just testing it but maybe next fall we will start using it with Jupyterhub. Awesome! If you have any question on xeus-cling, don't hesitate to hop on our permanent chat. https://gitter.im/QuantStack/Lobby?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1buZbfmJVnQKGPAT6glGWwG0TKR2uvks5tij3fgaJpZM4PRqYe> .

Answer 12 · 2018-03-27T14:16:15.000Z

The changes are in the upgrade-1.27 branch. They have been done long ago, I don't remember the state of that code.

I'm currently mentoring a programmer that could look into this in several weeks.

Answer 13 · 2018-03-27T14:37:12.000Z

Oh! That would be spiffy. :)

…

On Tue, Mar 27, 2018 at 10:16 AM Povilas Kanapickas < ***@***.***> wrote: The changes are in the upgrade-1.27 branch <https://github.com/p12tic/cppreference-doc/tree/upgrade-1.27>. They have been done long ago, I don't remember the state of that code. I'm currently mentoring a programmer that could look into this in several weeks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1buYzXX_PbnHE2t2Tvk-qBFVWvGfKHks5tikmwgaJpZM4PRqYe> .

Answer 14 · 2018-03-28T20:18:39.000Z

Hmm, why is CSS working over HTTPS for https://en.cppreference.com/w/cpp/container/map
but not the other pages, like https://en.cppreference.com/w/cpp/container/vector

Answer 15 · 2018-03-28T22:03:34.000Z

I think that if Nate has turned on https temporarily, then some pages might have been cached within MediaWiki with https links to stylesheets, thus they work.

@natekohl: Could it be that the reason you saw https not working was that you saw cached pages? I think MediaWiki does not purge HTTP cache automatically after configuration changes. A quick way to verify would be to add ?action=purge to a URL of a broken page when https is on.

Answer 16 · 2018-03-28T22:11:15.000Z

holy crap, purging indeed fixes https://en.cppreference.com/w/cpp/container/vector. i'm gonna kick myself if that's all we needed to do this whole time

…

On Wed, Mar 28, 2018 at 6:03 PM Povilas Kanapickas ***@***.***> wrote: I think that if Nate has turned on https temporarily, then some pages might have been cached within MediaWiki with https links to stylesheets, thus they work. @natekohl <https://github.com/natekohl>: Could it be that the reason you saw https not working was that you saw cached pages? I think MediaWiki does not purge HTTP cache after configuration changes. A quick way to verify would be to add ?action=purge when https is on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1buVHhfLQN6FqqfM5K0f61H-mpj9U7ks5tjAi7gaJpZM4PRqYe> .

Answer 17 · 2018-03-28T22:18:25.000Z

This seems to work, but we still need to do ?action=purge on each new page (I just did it on the front page).
Can it be done globally?

Answer 18 · 2018-03-28T22:20:15.000Z

I just purged the global cache; in theory, all pages should be re-created as they are visited now.

…

On Wed, Mar 28, 2018 at 6:18 PM Sylvain Corlay ***@***.***> wrote: This seems to work, but we still need to do ?action=purge on each new page (I just did it on the front page). Can it be done globally? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe> .

Answer 19 · 2018-03-28T22:27:52.000Z

hm, touching the file that defines $wgCacheEpoch seems to have only partially worked. I wonder if there is a race between HTTP and HTTPS traffic to get into the cache or something...

…

On Wed, Mar 28, 2018 at 6:19 PM Nate Kohl ***@***.***> wrote: I just purged the global cache; in theory, all pages should be re-created as they are visited now. On Wed, Mar 28, 2018 at 6:18 PM Sylvain Corlay ***@***.***> wrote: > This seems to work, but we still need to do ?action=purge on each new > page (I just did it on the front page). > Can it be done globally? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#49 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe> > . >

Answer 20 · 2018-03-28T22:31:55.000Z

@natekohl I think you can just delete the en, de, etc. directories within the cache directory - that's where all the html files reside. Be sure not to delete .htaccess accidentally :-)

Answer 21 · 2018-03-28T22:32:15.000Z

ah, $wgCacheEpoch probably only works on old MW installations. I'll try to figure out the new way to invalidate all cache entries.

…

On Wed, Mar 28, 2018 at 6:27 PM Nate Kohl ***@***.***> wrote: hm, touching the file that defines $wgCacheEpoch seems to have only partially worked. I wonder if there is a race between HTTP and HTTPS traffic to get into the cache or something... On Wed, Mar 28, 2018 at 6:19 PM Nate Kohl ***@***.***> wrote: > I just purged the global cache; in theory, all pages should be re-created > as they are visited now. > > On Wed, Mar 28, 2018 at 6:18 PM Sylvain Corlay ***@***.***> > wrote: > >> This seems to work, but we still need to do ?action=purge on each new >> page (I just did it on the front page). >> Can it be done globally? >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <#49 (comment)>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe> >> . >> >

Answer 22 · 2018-03-28T22:50:57.000Z

I tried deleting the cache/ and was...somewhat...successful. Parts of it weren't deletable, presumably because they were being concurrently written to by MediaWiki.

…

On Wed, Mar 28, 2018 at 6:31 PM Povilas Kanapickas ***@***.***> wrote: @natekohl <https://github.com/natekohl> I think you can just delete the directories within the cache directory - that's where all the html files reside. Be sure not to delete .htaccess accidentally :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1buUHqGYI_NofSFXU6NI7gE5DmEZ74ks5tjA9cgaJpZM4PRqYe> .

Answer 23 · 2018-03-29T04:27:19.000Z

A more thorough delete of the cache didn't seem to help. Pages loaded via HTTPS still try to load HTTP stylesheets, until ?action=purge is appended, after which they correctly load HTTPS stylesheets.

…

On Wed, Mar 28, 2018 at 6:50 PM Nate Kohl ***@***.***> wrote: I tried deleting the cache/ and was...somewhat...successful. Parts of it weren't deletable, presumably because they were being concurrently written to by MediaWiki. On Wed, Mar 28, 2018 at 6:31 PM Povilas Kanapickas < ***@***.***> wrote: > @natekohl <https://github.com/natekohl> I think you can just delete the > directories within the cache directory - that's where all the html files > reside. Be sure not to delete .htaccess accidentally :-) > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#49 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA1buUHqGYI_NofSFXU6NI7gE5DmEZ74ks5tjA9cgaJpZM4PRqYe> > . >

Answer 24 · 2018-03-29T11:23:42.000Z

Even with ?action=purge I am seeing some issues with the loading of javascript assets from CDNs over http.

Maybe these could be always loaded via https?

'https://en.cppreference.com/w/cpp/container/vector' was loaded over HTTPS, but requested an insecure script 'http://cdn.jsdelivr.net/ace/1.2.4/noconflict/ace.js'. This request has been blocked; the content must be served over HTTPS.

Answer 25 · 2018-03-30T22:47:04.000Z

@natekohl It seems there are other caches where various bits of information are cached. Maybe running purgeList.php --all --purge maintenance script would help?

Answer 26 · 2018-03-30T23:01:08.000Z

@SylvainCorlay: The http://cdn.jsdelivr.net/ace/1.2.4/noconflict/ace.js script issue is caused by https://github.com/p12tic/cppreference-doc/blob/master/gadgets/coliru_compiler.js#L548. I've fixed this few seconds ago on the wiki. Unfortunately it seems that http://coliru.stacked-crooked.com/ does not yet support https and we will need some kind of workaround for the "Run this code" button to work.

Answer 27 · 2018-04-26T01:41:49.000Z

It looks like a competing cache issue. Have we tried setting $wgServer to a protocol-relative URL?

Answer 28 · 2018-04-27T13:30:21.000Z

Yeah, this does kinda feel like two caches are fighting with eachother. Using ?action=purge on a page works for a minute or two, but then *something* happens and the old broken behavior returns.

…

On Wed, Apr 25, 2018 at 9:41 PM timsong-cpp ***@***.***> wrote: It looks like a competing cache issue. Have we tried setting $wgServer <https://www.mediawiki.org/wiki/Manual:$wgServer> to a protocol-relative URL? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#49 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1bufjtXFzSrt8anrxOgTVDxFGEvG1wks5tsSXdgaJpZM4PRqYe> .

Answer 29 · 2018-04-27T13:48:21.000Z

Maybe switching over $wgServer to https has helped with the competing cache problem -- let's see if it sticks. In the meantime, it looks like the syntax-highlighted links generated by GeSHi are hardcoded to http, so pages like https://en.cppreference.com/w/cpp/utility/tuple/make_tuple will have a mix of https and http links.

…

On Fri, Apr 27, 2018 at 9:29 AM Nate Kohl ***@***.***> wrote: Yeah, this does kinda feel like two caches are fighting with eachother. Using ?action=purge on a page works for a minute or two, but then *something* happens and the old broken behavior returns. On Wed, Apr 25, 2018 at 9:41 PM timsong-cpp ***@***.***> wrote: > It looks like a competing cache issue. Have we tried setting $wgServer > <https://www.mediawiki.org/wiki/Manual:$wgServer> to a protocol-relative > URL? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#49 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AA1bufjtXFzSrt8anrxOgTVDxFGEvG1wks5tsSXdgaJpZM4PRqYe> > . >

Answer 30 · 2018-04-27T15:51:51.000Z

I meant a protocol-relative URL like //en.cppreference.com etc. (which will follow whatever protocol you are currently using), not just making it https.

The GeSHi thing is probably hardcoded somewhere and should be switched over.