search

p12tic / cppreference-doc

C++ standard library reference
en.cppreference.com
GNU General Public License v3.0
416 stars 106 forks source link

Use https #49

Closed SylvainCorlay closed 7 years ago

SylvainCorlay commented 7 years ago

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?

p12tic commented 7 years ago

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.

SylvainCorlay commented 7 years ago

Thanks! Closing this issue.

SylvainCorlay commented 7 years ago

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

cc @natekohl

p12tic commented 7 years ago

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

SylvainCorlay commented 7 years ago

Thanks. I could edit the comments page! 👍

sigurdurb commented 6 years ago

@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.

SylvainCorlay commented 6 years ago

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++?

p12tic commented 6 years ago

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.

sigurdurb commented 6 years ago

@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.

SylvainCorlay commented 6 years ago

@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

natekohl commented 6 years ago

@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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-376523824, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buZbfmJVnQKGPAT6glGWwG0TKR2uvks5tij3fgaJpZM4PRqYe .

p12tic commented 6 years ago

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.

natekohl commented 6 years ago

Oh! That would be spiffy. :)

On Tue, Mar 27, 2018 at 10:16 AM Povilas Kanapickas < notifications@github.com> 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-376541470, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buYzXX_PbnHE2t2Tvk-qBFVWvGfKHks5tikmwgaJpZM4PRqYe .

povilas commented 6 years ago

huh? :)

sigurdurb commented 6 years ago

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

p12tic commented 6 years ago

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.

natekohl commented 6 years ago

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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377052714, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buVHhfLQN6FqqfM5K0f61H-mpj9U7ks5tjAi7gaJpZM4PRqYe .

SylvainCorlay commented 6 years ago

woot!

SylvainCorlay commented 6 years ago

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?

natekohl commented 6 years ago

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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377056539, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe .

natekohl commented 6 years ago

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 nate.kohl@gmail.com 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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377056539, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe .

p12tic commented 6 years ago

@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 :-)

natekohl commented 6 years ago

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 nate.kohl@gmail.com 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 nate.kohl@gmail.com 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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377056539, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buXIDF9HuG1S3BNnAx6Ma5uce635gks5tjAw2gaJpZM4PRqYe .

natekohl commented 6 years ago

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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377059640, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buUHqGYI_NofSFXU6NI7gE5DmEZ74ks5tjA9cgaJpZM4PRqYe .

natekohl commented 6 years ago

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 nate.kohl@gmail.com 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 < notifications@github.com> 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-377059640, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1buUHqGYI_NofSFXU6NI7gE5DmEZ74ks5tjA9cgaJpZM4PRqYe .

SylvainCorlay commented 6 years ago

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.
p12tic commented 6 years ago

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

p12tic commented 6 years ago

@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.

timsong-cpp commented 6 years ago

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

natekohl commented 6 years ago

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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-384485794, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1bufjtXFzSrt8anrxOgTVDxFGEvG1wks5tsSXdgaJpZM4PRqYe .

natekohl commented 6 years ago

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 nate.kohl@gmail.com 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 notifications@github.com 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 https://github.com/p12tic/cppreference-doc/issues/49#issuecomment-384485794, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1bufjtXFzSrt8anrxOgTVDxFGEvG1wks5tsSXdgaJpZM4PRqYe .

timsong-cpp commented 6 years ago

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.