pierre-alain-b / rainloop-nextcloud

Rainloop plugin for Nextcloud
110 stars 37 forks source link

Blank Screen with NC 19.0 and Rainloop 7.0.1 #201

Closed Pecadis closed 4 years ago

Pecadis commented 4 years ago

Hi Alain,

first, i would like to thank you for your work. I am using Rainloop since Years and really appreciate your doing. I have lately upgraded to 19.0 by accident and have seen that Rainloop just started showing a blank Screen when opening the App. Do you have an idea where this could come from?

I have seen that the Browser Console is refusing to execute some scripts because the Mime Type doesn't match.

image

However, even if i disable the header "X-Content-Type-Options" in nginx, it still doesn't work. The Logs in RL itself seems to be fine and connecting to the Mailserver Properly as it should.

How can i support you to solve this issue?

Best Regards

pierre-alain-b commented 4 years ago

Which browser are you using? Could you share a screenshot of what you see with Rainloop? i understand that you say that you say that despite not being visible Rainloop is connecting appropriately to the mail server, right?

twieskot commented 4 years ago

The same for me, im using Firefox 77.0.1 (64-bit)

failure

Pecadis commented 4 years ago

I am using the Brave Browser(V1.9.76) but have also checked it with Firefox (77.0.1 (64-Bit) ) and Chrome (83.0.4103.97)

I am basically just seeing the following: image

and yes, Rainloop seems to connect to the Mailserver in the Background (seen in the Logs) but is not displaying it in the Browser.

fracarvic commented 4 years ago

Same here. Tested with latest versions of Edge Chromium and Firefox.

Problem since upgrade to Nextcloud 19. I'm using official nextcloud docker image.

nextgen-networks commented 4 years ago

@fracarvic I've tested it couple of moments ago on my installed Edge (Chrome base 83.0.478.45) and Rainloop works without a hassle. Very strange. ... do you have any extension installed and advanced/custom rules applied (uBlock Origin, ...)?

twieskot commented 4 years ago

uBlock origin (but disabling it doesn't have any effect)

pierre-alain-b commented 4 years ago

No issue here with ublock and FF 77d 64 bits. No warning either. Are you all serving Nextcloud with Nginx?

Pecadis commented 4 years ago

Yes, i am using nginx.


Von: Pierre-Alain Bandinelli notifications@github.com Gesendet: Montag, 8. Juni 2020 13:07 An: pierre-alain-b/rainloop-nextcloud Cc: Pecadis; Author Betreff: Re: [pierre-alain-b/rainloop-nextcloud] Blank Screen with NC 19.0 and Rainloop 7.0.1 (#201)

No issue here with ublock and FF 77d 64 bits. No warning either. Are you all serving Nextcloud with Nginx?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

pierre-alain-b commented 4 years ago

Can you check the MIME type of the file polyfill.js returned by the server? image

pierre-alain-b commented 4 years ago

Anything special in your nginx config? Any change in the MIME type of some files?

pierre-alain-b commented 4 years ago

Also can you check if mime.types get loaded properly (check nginx logs) or if you get configuration errors (nginx -t)?

Pecadis commented 4 years ago

Polyfills list listed as text/html

nginx conf is working fine:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

I am using the default Nextcloud configuration. This is the Block which should affect the it

 # Adding the cache control header for js and css files
 # Make sure it is BELOW the PHP block
 location ~ \.(?:css|js|woff|svg|gif)$ {
   try_files $uri /index.php$uri$is_args$args;
   add_header Cache-Control "public, max-age=15778463";
   # Add headers to serve security related headers (It is intended to
   # have those duplicated to the ones above)
   # Before enabling Strict-Transport-Security headers please read into
   # this topic first.
   # add_header Strict-Transport-Security "max-age=15768000;           
   #  includeSubDomains; preload;";
   #
   # WARNING: Only add the preload option once you read about          
   # the consequences in https://hstspreload.org/. This option
   # will add the domain to a hardcoded list that is shipped
   # in all major browsers and getting removed from this list
   # could take several months.
   add_header X-Content-Type-Options nosniff;
   add_header X-XSS-Protection "1; mode=block";
   add_header X-Robots-Tag none;
   add_header X-Download-Options noopen;
   add_header X-Permitted-Cross-Domain-Policies none;
   # Optional: Don't log access to assets
   access_log off;
}
fracarvic commented 4 years ago

I'm using apache (with official nextcloud docker image) with default configuration, behind a nginx proxy (nginx-ingress, i'm using kubernetes) only with this config:

nginx.ingress.kubernetes.io/proxy-body-size: 512m 
nginx.ingress.kubernetes.io/configuration-snippet: |
  rewrite ^/.well-known/carddav https://$host/remote.php/dav/ redirect;
  rewrite ^/.well-known/caldav https://$host/remote.php/dav/ redirect;
  location /apps/rainloop/app/data { deny all; } 

Working perfectly with nextcloud 18 official docker image.

fracarvic commented 4 years ago

I'm not using any extensions on browser. Tested on my mobile (chrome for android) and same problem, white screen.

pierre-alain-b commented 4 years ago

OK so I think it is quite clear that the issue comes from the hosting. I have the feeling that all people impacted have the Nexctloud 19 official docker image. Correct?

Pecadis commented 4 years ago

Nope, i am not hosting it with docker. I am using php7.3 and nginx the traditional way.

pierre-alain-b commented 4 years ago

OK so maybe Nginx is the smallest common factor here...

Pecadis commented 4 years ago

That seems to be strange. What has been changed before with nc 18.x and now?

twieskot commented 4 years ago

i'm also working on a installation with docker+nginx

samsalway commented 4 years ago

docker + traefik, experiencing same problem, same browser logs about script mime type.

twieskot commented 4 years ago

Can you check the MIME type of the file polyfill.js returned by the server? image

image

pierre-alain-b commented 4 years ago

So we need to understand why the server Nginx is sending this weird mime/type for js files! Do you have anything around mime types in your respective Nginx configs?

Pecadis commented 4 years ago

Looking around, there is nothing else than i have already posted in regards to nginx and mime type. Even in the default /etc/nginx/mime.types File, the JS files are referenced correctly

types {
    text/html                                        html htm shtml;
    text/css                                         css;
    text/xml                                         xml;
    image/gif                                        gif;
    image/jpeg                                       jpeg jpg;
    application/javascript                           js;
    application/atom+xml                             atom;
    application/rss+xml                              rss;
pierre-alain-b commented 4 years ago

and yet the server is serving them as text/html...

fracarvic commented 4 years ago

I think the key here is the response code 302, a temporary redirection.

polifills.min.js returns a 302 redirection to /apps/files, and this response seems generated by nextcloud php, not apache or nginx.

More info, I'm using SSO with keycloak SAML.

pierre-alain-b commented 4 years ago

Indeed this is strange - we have something to follow! Can you look at the detailed reponse of the packet and share what you see? Clealry app/files shall be text/html so if there is a redirect by nextcoud to app/files then it is normal that this fails...

pierre-alain-b commented 4 years ago

Has anyone a public isntance where I could test the behavior as I cannot replicate it on my test and production instances?

fracarvic commented 4 years ago

ok, i think i find the problem.

I have two app folders, one for included apps and anoother for custom apps. In config.php:

  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),

Rainloop is installed in custom_apps and if I move to apps rainloop starts working perfectly.

fracarvic commented 4 years ago

Seems there are a confusion in paths, rainloop.js is loaded from custom_apps and is loading ok

https://xxxxxxx/custom_apps/rainloop/js/rainloop.js?v=680146ec-0

but polifill is requested in apps

https://XXXXX/apps/rainloop/app/rainloop/v/1.14.0/static/js/min/polyfills.min.js?community

and return 302 to default app (files) like any unexisting URL.

but if i try to load polifill from custom_apps is returned correctly

https://XXXX/custom_apps/rainloop/app/rainloop/v/1.14.0/static/js/min/polyfills.min.js?community

pierre-alain-b commented 4 years ago

It's because Rainloop app was not aware it could be installed in a custom apps folder! Could this be an explanation for all those impacted?

pierre-alain-b commented 4 years ago

@twieskot @Pecadis are you in a similar situation?

Pecadis commented 4 years ago

@pierre-alain-b indeed, i am using rainloop in a custom apps folder. i am trying to replicate that on a different machine currently.

waltherjj commented 4 years ago

@twieskot @Pecadis are you in a similar situation?

hi, just wanted to chime in on this: i experience the same problem and i'm using rainloop in a custom apps folder as well. it seems to me that all assets using the staticPath function in RainLoop/Service are not served correctly. That function traces to function WebPath in RainLoop/Utils which seems to hardcode the app path. Sadly i'm not familiar enough with the code base to propose a fix on the right level. Hope this helps a bit either way!

pierre-alain-b commented 4 years ago

I confirm I was not aware apps could be installed in custom folders - so indeed the path is currently hardcoded. We will try to fix this.

twieskot commented 4 years ago

@twieskot @Pecadis are you in a similar situation?

hi, just wanted to chime in on this: i experience the same problem and i'm using rainloop in a custom apps folder as well. it seems to me that all assets using the staticPath function in RainLoop/Service are not served correctly. That function traces to function WebPath in RainLoop/Utils which seems to hardcode the app path. Sadly i'm not familiar enough with the code base to propose a fix on the right level. Hope this helps a bit either way!

no, rainloop is in the default apps folder here: https://XXXXXXXXXXXXXX/apps/rainloop/

Pecadis commented 4 years ago

@twieskot just to be sure that we are on the same page and avoid misunderstandings. We are not talking about what is being displayed on the Browser like https://domain.example/apps/rainloop/ but rather how it has been setup in the config.php.

My relevant section here is this where Rainloop is indeed in my custom apps folder even if the URL part is indicating otherwise.

  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/customapps',
      'url' => '/customapps',
      'writable' => true,
    ),
  ),
twieskot commented 4 years ago

@twieskot just to be sure that we are on the same page and avoid misunderstandings. We are not talking about what is being displayed on the Browser like https://domain.example/apps/rainloop/ but rather how it has been setup in the config.php.

My relevant section here is this where Rainloop is indeed in my custom apps folder even if the URL part is indicating otherwise.

  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/customapps',
      'url' => '/customapps',
      'writable' => true,
    ),
  ),

Sorry, yes my fault. Same for me:

'apps_paths' => array ( 0 => array ( 'path' => '/var/www/html/apps', 'url' => '/apps', 'writable' => false, ), 1 => array ( 'path' => '/var/www/html/custom_apps', 'url' => '/custom_apps', 'writable' => true, ),

pierre-alain-b commented 4 years ago

I agree with this last comment: the URL is showing "/apps/" irrespective of the back-end path. So you should check the config.

I was able to replicate the bug on a test instance with the custom_apps folder. I would propose a hack that could temporarily fix the issue for those impacted (waiting for a better long term solution)

waltherjj commented 4 years ago

I agree with this last comment: the URL is showing "/apps/" irrespective of the back-end path. So you should check the config.

I was able to replicate the bug on a test instance with the custom_apps folder. I would propose a hack that could temporarily fix the issue for those impacted (waiting for a better long term solution)

this would be very much appreciated!

pierre-alain-b commented 4 years ago

Dirty hack for those in a hurry to re-establish access:

in /path/to/nextcloud/custom_apps/rainloop/app/rainloop/v/1.14.0/app/libraries/RainLoop/Utils.php

change

            if (empty($sAppPath))
            {
                $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
                if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
                {
                    $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                        '/apps/rainloop/app/', $sUrl);
                }
            }

into

            if (true)
            {
                $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
                if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
                {
                    $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                        '/custom_apps/rainloop/app/', $sUrl);
                }
            }

of course custom_apps shall be changed for the appropriate path!

fracarvic commented 4 years ago

Dirty hack for those in a hurry to re-establish access:

in /path/to/nextcloud/custom_apps/rainloop/app/rainloop/v/1.14.0/app/libraries/RainLoop/Utils.php

change

          if (empty($sAppPath))
          {
              $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
              if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
              {
                  $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                      '/apps/rainloop/app/', $sUrl);
              }
          }

into

          if (true)
          {
              $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
              if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
              {
                  $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                      '/custom_apps/rainloop/app/', $sUrl);
              }
          }

of course custom_apps shall be changed for the appropriate path!

changed code and working now !!!!

Thanks.

waltherjj commented 4 years ago

Dirty hack for those in a hurry to re-establish access:

in /path/to/nextcloud/custom_apps/rainloop/app/rainloop/v/1.14.0/app/libraries/RainLoop/Utils.php

change

          if (empty($sAppPath))
          {
              $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
              if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
              {
                  $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                      '/apps/rainloop/app/', $sUrl);
              }
          }

into

          if (true)
          {
              $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();
              if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))
              {
                  $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',
                      '/custom_apps/rainloop/app/', $sUrl);
              }
          }

of course custom_apps shall be changed for the appropriate path!

the proposed fix did not work for me as some of the assets still loaded from the wrong route. for others running into the same problem, another possible hack (that makes this work for me) is leaving the conditional block as is, but replacing the string in the return value, e.g.:

public static function WebPath()                                                                 
        {                                                                                                
                $sAppPath = '';                                                                          
                if (\RainLoop\Utils::IsOwnCloud())                                                       
                {                                                                                        
                        $sAppPath = \OC::$server->getURLGenerator()->linkToRoute('rainloop.page.appGet');
                        // TODO: Fix this ugly hack. Is there a "modern" way to return                   
                        // a URL that doesn't include index.php, which breaks things?                    
                        $sAppPath = preg_replace('/index\.php\//', '', $sAppPath);                       

                        if (empty($sAppPath))                                                            
                        {                                                                                
                                $sUrl = \MailSo\Base\Http::SingletonInstance()->GetUrl();                
                                if ($sUrl && \preg_match('/\/index\.php\/apps\/rainloop/', $sUrl))       
                                {                                                                        
                                        $sAppPath = \preg_replace('/\/index\.php\/apps\/rainloop.+$/',   
                                                '/apps/rainloop/app/', $sUrl);                           
                                }                                                                        
                        }                                                                                
                }                                                                                        
                return str_replace('/apps/rainloop/app', '/custom_apps/rainloop/app', $sAppPath); 

as mentioned above, replace custom_apps with your custom app folder.

matze0301 commented 4 years ago

Had the same Problem with white screen and only the second fix from @waltherjj worked for me. (NC/RL on Docker behind nginx Reverse Proxy) Thank you all :-)

conspacer commented 4 years ago

@waltherjj tmp solution worked. Tx NC 19 (official Docker) / Rainloop 7.0.1 / Nginx ReverseProxy with LE SSL

shankari commented 4 years ago

Just to confirm that it is not related to nginx in any way, my setup is:

@pierre-alain-b's hack did not work @waltherjj's hack worked

SebastianThuesen commented 4 years ago

I am running Nextcloud with snap on Ubuntu 20.04 LTS and Apache2 with reverse proxy module on another machine. RainLoop does work with 18.0.6snap1 with rainloop version 6.1.4 based on 1.14.0 RainLoop does not work with 19.0.0snap1 with rainloop version 7.0.1 based on 1.14.0

@waltherjj hack works.

To get the hack to work with NextCloud snap: outcomment this in the public static function WebPath(): return $sAppPath; and paste this in right above the out-commented code: return str_replace('/apps/rainloop/app', '/extra-apps/rainloop/app', $sAppPath); in the Utils.php file located at: /var/snap/nextcloud/current/nextcloud/extra-apps/rainloop/app/rainloop/v/1.14.0/app/libraries/RainLoop/

Rainloop will work after this for 19.0.0snap1

Another solution is just to revert from 19 to 18 trough the sudo snap revert nextcloud command

bsherwoodofdaptiv commented 4 years ago

Yeah. I hit this too. I am hosted in AWS Lightsail. Something upgraded my dam* install to 19.x behind my back. Turned off several 'untested' apps, and broke this. I really need to spin up a replacement server and hard install (not SNAP) Nextcloud, so things like this don't break.

bsherwoodofdaptiv commented 4 years ago

@SebastianThuesen -- thank you for how to do this with a SNAP setup. It helps all of us stuck with this auto-upgraded problem with SNAP.

relikd commented 4 years ago

Haven't read through the whole topic but wanted to create an issue for the same bug. My problem was (and still is) that I could not open the admin interface.

I figured the problem in my case. The generated html has links to static files that are not present on the server (404). But the URL is just slightly wrong. /apps/... instead of /extra-apps/...
Maybe its relevant that I have nextcloud installed via snap.

The WebStaticPath function seems to produce a wrong URL: https://github.com/pierre-alain-b/rainloop-nextcloud/blob/master/app/rainloop/v/1.14.0/app/libraries/RainLoop/Utils.php#L596

It produces:

/apps/rainloop/app/rainloop/v/1.14.0/static/js/min/boot.min.js?community

instead of:

/extra-apps/rainloop/app/rainloop/v/1.14.0/static/js/min/boot.min.js?community

I have no idea whether other parts may have wrong URLs too, but fixing this single line above at least shows the admin interface.

kyrofa commented 4 years ago

@bsherwoodofdaptiv FYI you don't need to be following the stable channel if you don't want to automatically update across major versions. Use sudo snap refresh nextcloud --channel=18 instead and you'll stay on v18 (minor version updates only) until you're ready to upgrade. See the snap release strategy page for more details. Also see what do I do if an update breaks Nextcloud.