Blocking mixed content: codepygments default.css #315
Comments
|
Hey @jpkeith4, That should be happening on this line in modular-file-renderer. Looking at that code, it appears as though it's using the same protocol as the request it receives. Can you open your network tab in your browser and local for a request to a url ending with Cheers, |
|
So it's https. Is it supposed to have 192.168.168.167:5000 though, or could that be the problem? Also, in case it offers any additional insight, I have tried getting a Firefox plugin to allow all mixed content and when I do that I then see a CORS request blocked from resource: http://share.mydomain/assets/pdf/web/locale/locale.properties If I further get a plugin to let all CORS blocks through then I get So I don't know if these are all separate issues or if they are related, but I just thought I'd mention them all. |
|
That's... strange. Could you inspect the HTML in the iframe and search for I wonder if having a domain w/o a tld might be confusing |
|
share.mydomain is just an example. The real main site domain is of the form project.host.com and for the various services OSF uses like share, api, accounts, and files they are of the form "project-share.host.com". So using those now "project-share.host.com" shows up as HTTPS several times outside the iframe, 1 time in the iframe src itself, and 0 times inside the iframe. Do you know if there is some configuration I missed that changes it there from HTTP to HTTPS? |
|
Hey @jpkeith4, I'm a bit confused now. What service is causing this problem? The URL you pasted in the first comments looks like an MFR url, but you've mentioned SHARE, which is a different service. I think you're trying to view a file on the OSF, which should not involve SHARE at all. It might involve share.js, which is the unfortunately-named service we use for collaborative text editing, but that's a separate service from SHARE. Can you post a screenshot of your page and a link to a pastebin or gist of the page source? That'll help me narrow down where the error is occurring. If you don't feel comfortable posting that in public on GH, feel free to email me at [email protected]. Also, what type of file are you trying to render? In the first comment it looks like some sort of plain-text or source code file, but the others seem like they might be pdfs. Cheers, |
|
Ok sorry for the confusion I guess I have weird names for the services, but this should actually be the mfr service. In the docker environment file I have it as MFR_SERVER_URL=https://project-share.host.com
[EDIT] |
|
Shot in the dark: after you set up the environment variables, did you do Now that the code in the iframe shows https, is the error still the same? Is it still making http requests? Is there anything new in the console logs? |
|
Well those envvars were set before any docker images, containers, or volumes were downloaded or built, so they should be applied. I actually just tried modifying the line you linked to here: here So this request too seems to be HTTP and considering that this is client side I'm guessing it shouldn't be requesting 192.168.168.167:7777 either. It seems something is just not configured right. Is there anything in waterbutler or mfr themselves that needs to be configured for this to work? Perhaps in waterbutler/settings? I don't see anything in there though that looks like it would help. But I'm under the impression that needs to remain as it is while the var "WATERBUTLER_URL" is set to the actual subdomain for that service (with https). However, just to see what happens if I do set them both to my subdomain for waterbutler then all files stop rendering. |
|
Hey @jpkeith4, You may need to set up WB & MFR to work on https internally as well as externally. Most folks on dev run everything over http. In production WB & MFR are different servers and do communicate over https. I don't think we've had anyone run the OSF in a mixed environment before. If you're already running those services on different hosts, you should be able to set Cheers, |
|
They're all currently running on the same machine. Everything seems to be working fine server side, and as far as I can tell the only issue is that the client is somehow ending up with WATERBUTLER_INTERNAL_URL when it comes time to request the files instead of WATERBUTLER_URL. If that's really the case it would seem like a bug to me, because the client can't always be expected to have access to the internal url right? Although, I actually got it completely working temporarily with pdfs using 2 workarounds. The one I mentioned in my previous post and also another one inside of file mfr/extensions/pdf/render.py I just added a line to the render function right before the return call just to replace "http://192.168.168.167:7777" with the actual mfr url and then it all renders just fine for the client. So this supports the idea that other than the internal url being sent to the client everything else seems to be functioning. |
|
Hey jpkeith4, My bad about changing the internal url. I thought you meant that you had changed it to |
On my local instance of the OSF I have everything running using HTTPS but I still see in my Firefox Javascript console that this one file is being requested with HTTP and therefore is blocked as mixed content.
This is frustrating because Firefox does not report any line number. It simply says it's coming from file "vgywd" which I suppose is the file ID and there is a corresponding Javascript file. But when I click on it, although it opens the file in the debugger it just opens it at the top and doesn't go to any particular line number. If I search the file for "codepygments" or "default.css" it has 0 results. The file is almost 1000 lines long so it would be a real pain to have to read through this to find out where it is making an HTTP request to the share server.
Does anyone have any idea how to fix this?
The text was updated successfully, but these errors were encountered: