Paperwork is not recognizing https connection and serves content via http

[JamborJan]

I have running paperwork behind a nginx webserver who redirects to the paperwork server. Everything is running via https managed by that nginx server.

I have only one issue: paperwork requests all css and js includes used via http which causes error message when loading the application. E.g. "Firefox has blocked insecure content" etc.

All CSS includes in the head are like this:

All JS includes at the end are like this:

<script src="http://server/js/bootstrap-editable.min.js"></script>

I tried to figure out how to force https here but have no solution so far. Any ideas?

Thanks
JJ

[jamesrascal]

It seems like there is an issue with you configuration. When HTTPS is enabled ( you can also turn on force HTTPS) the loaded JS and CSS files are pulled through HTTPS and not over HTTP.

If you would like to post your current configuration its possible that you are missing something that forwards it over HTTPS (port 443) vs HTTP (port 80).

[JamborJan]

Where do I set this in paperwork?

The server which is running paperwork has nothing more than minimum configuration. The local nginx server has no ssl configured. Only the one forwarding to that.

Thanks.

[jamesrascal]

I would recommend that the server you have Paperwork installed on setting up SSL.

Configure Nginx on that box to listen on port 443 and adjust the config file for paperwork to force HTTPS: /paperwork/frontend/app/config/paperwork.php

[JamborJan]

Thanks for your help so far @jamesrascal but unfortunately in my use case it's not possible to setup ssl in the container where paperwork is running.

The /paperwork/frontend/app/config/paperwork.phpalready says it's running on forced https. But I still have the issue that CSS and JS are loaded via http and thus the side looks crap because browsers are blocking these resources as a result of being not encrypted.

Is there any chance that I can force or hack paperwork that it always uses https for those includes? It' doesn't need to detect something here simply always use https for that piece of code.

[Liongold]

I think I've found a solution for your problem. Can you give me some time
to do a fix for it, please?

On Thursday, March 19, 2015, JJ notifications@github.com wrote:

Thanks for your help so far @jamesrascal https://github.com/jamesrascal
but unfortunately in my use case it's not possible to setup ssl in the
container where paperwork is running.

The /paperwork/frontend/app/config/paperwork.phpalready says it's running
on forced https. But I still have the issue that CSS and JS are loaded via
http and thus the side looks crap because browsers are blocking these
resources as a result of being not encrypted.
[image: bildschirmfoto_2015-03-19_um_08_32_23]
https://cloud.githubusercontent.com/assets/7508960/6726138/de52e364-ce13-11e4-98ad-cf431a563c1b.png

[image: bildschirmfoto_2015-03-19_um_08_32_51]
https://cloud.githubusercontent.com/assets/7508960/6726154/feb66b58-ce13-11e4-9349-fc9f6992bffd.png

[image: bildschirmfoto 2015-03-19 um 08 42 53]
https://cloud.githubusercontent.com/assets/7508960/6726157/041feb8c-ce14-11e4-83e7-217cd7ef474b.png

Is there any chance that I can force or hack paperwork that it always uses
https for those includes? It' doesn't need to detect something here simply
always use https for that piece of code.

—
Reply to this email directly or view it on GitHub
#281 (comment).

Sincerely,
Jean Spiteri.

[JamborJan]

Sure! Take all the time you need. Would be really good if you can send me a quick hack beginning next week. Thanks a lot @Liongold

[Liongold]

@JamborJan Can you check if the value specified in here is the same as the URL used to access your install of Paperwork (URL)?

[Liongold]

I mean in your config files of course

[JamborJan]

Strange, I didn't take care about that so far. No it's not the same. The tricky part is: I'm working on the sandstorm.io port of paperwork where the app is running in a container which will be accessed later by a partial random domain e.g. randomstuff.server.com this because you can create a new instance by clicking on a button.

[Liongold]

@JamborJan Just to very if that's the problem, can you change the config value and see if it works?

[JamborJan]

I included there now the complete URL of one test instance of a container but it's not working. The odd thing is: without having taking care about this line: https://github.com/twostairs/paperwork/blob/develop/frontend/app/config/paperwork.php#L26 before the app found the complete correct URL of the JS and CSS which are required.

[Liongold]

@JamborJan So it still did not work? I didn't understand the complete second statement.

[JamborJan]

No it didn't work.

I can literary put "anything.com" in that line. It has no affect. The page is loading. It only doesn't know weather it should do a http or https.

Hope that clarifies something.

[Liongold]

@JamborJan You can't share the config file you are running right?

[JamborJan]

Sure I can. So far I used the default without taking care. I changed now the domain and also tryed to adjust the port, reason is point 1 below. To understand completely what I have done so far:

1. I created a docker container with paperwork, see https://github.com/JamborJan/paperwork/blob/master/Dockerfile (exposed to port 33411)
2. I then export the last status of that container: https://github.com/JamborJan/paperwork/blob/master/export_docker.sh
3. Then I create a sandstorm specific container out of that

Why I'm doing all the stuff: the URL will be dynamically for each running instance. So it will not be possible to use a fixed DNS in the config file.

[Liongold]

Ok, I'll try and post the idea I had yesterday in a few minutes.

[JamborJan]

here is my config so far: https://gist.github.com/JamborJan/497a965529938782d0ed

[Liongold]

@JamborJan Can you try running the code in branch issue-281-investigation of this repo, please?

[JamborJan]

I guess these changes are required: dabdc0a?

Will check it right now.

[JamborJan]

Have to improve my GitHub skills a bit, pulling the changes without deleting mine and switching the branch -.-

[Liongold]

@JamborJan Those are the only changes made to the branch. You can checkout the whole branch, so no need to touch your develop branch.

[Liongold]

Try git checkout issue-281-investigation and run gulp

[JamborJan]

Okay I'm running now on upstream/issue-281-investigation but have the same, you can check it here: https://paperwork.pandorica.centur.io/login

[Liongold]

@JamborJan Can you include a die(Request::secure()) somewhere in the Laravel code?

[JamborJan]

any specific place required?

[Liongold]

No.

[JamborJan]

Sorry, I'm too stupid to find a place where I can put it with a usable result ... can you specify where I should place it?

[Liongold]

I understand if you are frustrated with this but a hack can be done. However, it can't be applied anywhere and requires several changes. If it isn't a problem for you, I'd like you to help me to turn the hack into correct code that can be used by all.

[JamborJan]

As mentioned before: I'm here for testing :-)

Today I have to make a break in one hour or so but tomorrow I have plenty of time.

[Liongold]

Ok, I'll try to get back to you as soon as possible. If you're not here, don't worry.

[Liongold]

@JamborJan I'm not sure that you're online right now. However, whenever you can could you please repull the latest commit I made in the issue-281-investigation?

[JamborJan]

Will do the test in approx one hour and let you know. Thanks so far for your help.

[Liongold]

No problem.

[JamborJan]

Hey @Liongold , I merged your changes and tested it. Unfortunately no better result so far. See: https://paperwork.pandorica.centur.io

Let me know if I can provide anything more to make your work easier.

[Liongold]

Sorry for asking you again to do this but could you re-pull the latest changes to the issue-281-investigation. It isn't fit to be in the actual code but could be a way to fix your problem until a real fix is found (if it works in the first place).

[Liongold]

@JamborJan: forgot to tag you.

[JamborJan]

Congratulations @Liongold! You made it! My first test instance is working with that change. Now I would have to apply this to my master branch and test it in my containers.

[Liongold]

I knew of that option right from the start but hoped of finding a real solution to the problem. Apologies for maybe wasting your time but I hope you understand my reasons and I'm still hoping you could help me to fix the real issue.

[JamborJan]

No Problem. I will build my package with that quick-fix and will keep testing the stuff you provide, no problem at all. Simply let me know when you need something from my side.

[Liongold]

Do you want to use Gitter to avoid adding a lot of comments to this issue?

[JamborJan]

Sure.

[JamborJan]

The problem is that Paperwork doesn't recognize if it should provide content via http or https.

In my scenario the HTTP_X_FORWARDED_PROTOis set to https and I also have set HTTPS to be "on" with the following:

if ((array_key_exists('HTTP_X_FORWARDED_PROTO', $_SERVER) ? $_SERVER[ 'HTTP_X_FORWARDED_PROTO'] : 'HTTP_X_FORWARDED_PROTO not set') == "https") $_SERVER['HTTPS'] = "on";

I included that line in paperwork/frontend/app/config/paperwork.php, I'm not sure if that is the right place.

Anyway the app is not properly building the page with https. So I had to replace in all paperwork/frontend/app/views/layoutthe includes like this:

Old: [[ HTML::style('css/themes/paperwork-v1.min.css') ]]
New:  <link media="all" type="text/css" rel="stylesheet" href="css/themes/paperwork-v1.min.css">

There is also an issue with forms, e.g. the login form in paperwork/frontend/app/views/user/login.blade.php. It also sends data via http. I have replaced the dynamic code with actual <form> tags and a relative action URL.

Can you please check why the app is not recognizing that it should serve content via https? As I have been asked for certain debug output here are my test results:

Added lines in paperwork/frontend/app/controllers/UserController.php:

        echo array_key_exists('HTTPS', $_SERVER) ? $_SERVER[ 'HTTPS'] : 'HTTPS not set'."<br>";
        echo $_SERVER['SERVER_PORT']."<br>";
        echo array_key_exists('HTTP_X_FORWARDED_PROTO', $_SERVER) ? $_SERVER[ 'HTTP_X_FORWARDED_PROTO'] : 'HTTP_X_FORWARDED_PROTO not set';
        die();

Output:

on
33411
https

PS: the port id correctly set in paperwork/frontend/app/config/paperwork.php

I'm here for testing, my fork with all my changes is here: https://github.com/JamborJan/paperwork

Thanks!

[JamborJan]

Additional places I found where abolute paths are used instead of realtive which makes live uneccesairy hard:

When logged in as user and looking ant the page source:

[...]
<a class="paperwork-logo navbar-brand transition-effect" 
[...]

[...]
<ul class="nav navbar-nav navbar-right">
    <li><a href="http://paperwork.pandorica.centur.io" class="transition-effect"><i class="fa fa-book"></i> <span class="hidden-sm hidden-md">Library</span></a></li>
    <li><a href="http://paperwork.pandorica.centur.io/profile" class="transition-effect"><i class="fa fa-user"></i> <span class="hidden-sm hidden-md">Profile</span></a></li>
    <li><a href="http://paperwork.pandorica.centur.io/settings" class="transition-effect"><i class="fa fa-cog"></i> <span class="hidden-sm hidden-md">Settings</span></a></li>
            <li><a href="http://paperwork.pandorica.centur.io/admin" class="transition-effect"><i class="fa fa-star"></i> <span class="hidden-sm hidden-md">Admin Area</span></a></li>
        <li><a href="http://paperwork.pandorica.centur.io/help" class="transition-effect"><i class="fa fa-question"></i> <span class="hidden-sm hidden-md">Help</span></a></li>
    <li><a href="http://paperwork.pandorica.centur.io/logout" class="transition-effect"><i class="fa fa-sign-out"></i> <span class="hidden-sm hidden-md">Sign out</span></a></li>
</ul>href="http://paperwork.pandorica.centur.io"><img src="/images/navbar-logo.png"> Paperwork</a>
[...]

[...]
<form method="POST" action="http://paperwork.pandorica.centur.io" accept-charset="UTF-8" class="form-signin" role="form"><input name="_token" type="hidden" value="4DaDSrI1I7eHNvZpWdkYEbzFAldMCLd91juklQK3">
[...]

The form mentioned is appearing two times in the code.

[JamborJan]

See my fork for details how I solved the issue for now.

HTTP / HTTPS: get the right protocol and depending on that force Paperwork to use the right one:
https://github.com/JamborJan/paperwork/blob/master/frontend/app/routes.php

Plus relative paths in the view/layouts.

[ghost]

@JamborJan how about coming up with a pull request to fix that?

[JamborJan]

@baldrs I can do that but I'm not sure if my solution is super smart or just a bloody workaround :-)

My solution seems to work but I would test it a bit more, don't want to crap your code. Is there anybody able to review what I have done and tell me if it makes sense?

[mrusme]

@JamborJan I just flew over this issue, without spending as much thoughts on it as you guys did. Just a hint from my side: It's probably not the best solution if things like HTML::style needs to be replaced by a hardcoded link tag. In general, I would say that all this fixing should be done in Laravel, rather than within Paperwork, as it's the framework that needs to provide us with the HTTP_X_FORWARDED_PROTO feature.

[Liongold]

@devilx I am currently working with @JamborJan on a way to fix this issue as good and Laravel-friendly way as possible.

[ghost]

I've fixed that in #360 because I was unable to run paperwork in a subfolder via https.