Internal Server Error Exchange365

[Jan-Gerrit]

After entering the Microsoft 365 Authentication Settings, I try to log in to Exchange 365 via the Connected Accounts tab. The login window opens and I can log in successfully to Exchange 365 . After the Login, the error then appears.

Internal Server Error The server was unable to complete your request. If this happens again, please send the technical details below to the server administrator. More details can be found in the server log.

In the Nextcloud-Log the following error message appears

_OCA\EWS\Controller\UserConfigurationController::ConnectMS365(): Argument #1 ($code) must be of type string, null given, called in /var/www/html/cloud.XXX.de/lib/private/AppFramework/Http/Dispatcher.php on line 230 in file '/var/www/html/cloud.XXX.de/apps/integrationews/lib/Controller/UserConfigurationController.php' line 119

The Microsoft Exchange 365 configuration was created using these instructions: https://github.com/ksainc/integration_ews/blob/main/docs/o365.md

Debian10 Apache2.4 PHP 8.1.27 Memory limit: 8 GB Max execution time: 3600 Upload max size: 16 GB OPcache Revalidate Frequency: 1

Extensions: Core, date, libxml, openssl, pcre, zlib, filter, hash, json, Reflection, SPL, session, standard, sodium, cgi-fcgi, mysqlnd, PDO, xml, apcu, bcmath, bz2, calendar, ctype, curl, dom, mbstring, FFI, fileinfo, ftp, gd, gettext, gmp, iconv, igbinary, imagick, intl, ldap, exif, mysqli, pdo_mysql, Phar, posix, readline, redis, shmop, SimpleXML, smbclient, soap, sockets, sysvmsg, sysvsem, sysvshm, tokenizer, xmlreader, xmlwriter, xsl, zip, libsmbclient, Zend OPcache

[ksainc]

Good Morning @Jan-Gerrit

So the error is occurring in this code block,

https://github.com/ksainc/integration_ews/blob/7f2eb5b5d97e1d8b38ab014594640b0fb24872c9/lib/Controller/UserConfigurationController.php#L119-L138

This code block handles the response/redirect from O365. Once you authenticate with O365 you get redirected to "https://(your domain)/apps/integration_ews/connect-ms365?code=(the O365 access code)"

According to your error, the "code" part of the URL is blank, even tough I can see the "code" in the URL from the screen shot you sent.

Are you using a proxy of some sort? Or some kind of filter? That would be filtering out the code part.

[Jan-Gerrit]

Thank you for your quick reply

No, there is no proxy installed in front of it. Here is my apache configuration:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin XXX
        ServerName XXX
        ServerAlias www.cloud.XXX
        DocumentRoot /var/www/html/cloud.XXX/

        <Directory /var/www/html/cloud.XXX/>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews

          <IfModule mod_dav.c>
            Dav off
          </IfModule>
        </Directory>

        <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
        </IfModule>

        <FilesMatch \.php$>
          SetHandler "proxy:unix:/run/php/php8.1-fpm.sock|fcgi://localhost"
        </FilesMatch>

SSLCertificateFile /etc/letsencrypt/live/cloud.XXX/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.XXX/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

If I understand correctly, it is because O365 transferred not the required value here. So it is a missconfiguration in O365. Am I right about that?

The required authorization is set

https://cloud.XXX/apps/integration_ews/connect-ms365?code=0.AXkAIDgda0AZi....... (very long URL) Should there be a different response at code=0.AX?

[ksainc]

No. Looks like the redirect is working properly.

BUT, NC is phrasing the "code" argument wrong, before it passes it to the App. In your screen shot, I can see the "code" argument exists (this means O365 sent the value) but when NC runs the "UserConfigurationController::ConnectMS365" function the value of the code arrangement is "NULL" (nothing). So this is either an NC issue or Apache issue...

This is correct... "https://cloud.xxx/apps/integration_ews/connect-ms365?code=0.AXkAIDgda0AZi.......#" (very long URL)

Here is mine from a test I just did... "https://localhost/apps/integration_ews/connect-ms365?code=0.AW8AAhYC7nSSxkmxx5ZxjIV.......#"

So there is something inside your NC setup that is causing this. If you have the ability to see the Apache access logs, you should be able to see a request like this one...

"172.22.96.1 - - [14/Feb/2024:08:52:52 -0500] "GET /apps/integrationews/connect-ms365?code=0.AW8AAhYC7nSSxkmxx5ZxjIV.......#&session_state=62f70b65-2fab-439b-b5a3-ad90b73d60a1 HTTP/2.0" 200 8972 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0"

This will show you what Apache is seeing.

You can submit the URL you have in a new browser windows, and watch the apache logs.

[arno1979]

Hi,

@ksainc Thanks for the guide!

I redid my setup according to your guide and sadly I experienced the exact same problems as @Jan-Gerrit described them above. My Nextcloud log output looks exactly like his so I will not post it again. As you suggested I had a look at the Apache access log but everything looks good to me. It's the same error I got before I used your guide to set up the app permissions in the Microsoft 365 backend. I am kind of at a loss here but at least I am not the only one having this problem.

[Jan-Gerrit]

No. Looks like the redirect is working properly.

BUT, NC is phrasing the "code" argument wrong, before it passes it to the App. In your screen shot, I can see the "code" argument exists (this means O365 sent the value) but when NC runs the "UserConfigurationController::ConnectMS365" function the value of the code arrangement is "NULL" (nothing). So this is either an NC issue or Apache issue...

This is correct... "https://cloud.xxx/apps/integration_ews/connect-ms365?code=0.AXkAIDgda0AZi.......#" (very long URL)

Here is mine from a test I just did... "https://localhost/apps/integration_ews/connect-ms365?code=0.AW8AAhYC7nSSxkmxx5ZxjIV.......#"

So there is something inside your NC setup that is causing this. If you have the ability to see the Apache access logs, you should be able to see a request like this one...

"172.22.96.1 - - [14/Feb/2024:08:52:52 -0500] "GET /apps/integrationews/connect-ms365?code=0.AW8AAhYC7nSSxkmxx5ZxjIV.......#&session_state=62f70b65-2fab-439b-b5a3-ad90b73d60a1 HTTP/2.0" 200 8972 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0"

This will show you what Apache is seeing.

You can submit the URL you have in a new browser windows, and watch the apache logs.

I checked the access.log and it is the same entry as yours. Therefore I would say that apache passes the url correctly

[ksainc]

Hi @arno1979 and @Jan-Gerrit

Okay, so it seems you are both using Apache. I have been testing and using Nginx as a web server using a PHP socket. If Apache is seeing the correct URL being submitted, then the next thing that could be causing the problem is what Apache is passing to PHP.

Can you give me a bit of details on how your Apache is connected to PHP? What PHP module are you using? (php-fpm, etc) Are you using PHP via TCP connection (server 127.0.0.1:9000;) or socket (server unix:/var/run/php/php8.2-fpm.sock)?

[arno1979]

Hi @ksainc that is correct I am using Apache and running PHP-FPM 8.2.15 through a proxy handler in my virtual host configuration: SetHandler "proxy:unix:/var/run/php-fpm/php-fpm.sock|fcgi://localhost"

[ksainc]

@arno1979

Okay, so if I read this correctly you are using FPM on a socket with a or FCGI?

Could you test this with just FPM on a socket. Basically remove the "|fcgi://localhost" part.

[ksainc]

@arno1979

Okay, so if I read this correctly you are using FPM on a socket with a or FCGI?

Could you test this with just FPM on a socket. Basically remove the "|fcgi://localhost" part.

Never mind ignore my this, this will not work.

[ksainc]

Hi @arno1979 and @Jan-Gerrit,

Seems this might be your issue.

https://stackoverflow.com/questions/7724270/max-size-of-url-parameters-in-get

Basically, I think either there is some kind of parameter length limit on Apache or FPM.

[arno1979]

Seems this might be your issue.

https://stackoverflow.com/questions/7724270/max-size-of-url-parameters-in-get

Basically, I think either there is some kind of parameter length limit on Apache or FPM.

I looked into this and even tried to add the suhosin parameter to my php.ini but it doesn't change anything. I think this simply has to do with the fact that the Suhosin PHP extension is not developed anymore and adding the parameters has no effect as they are simply ignored. The last Suhosin release was in 2015 and there is no version available for PHP 8.x.

While researching this I read multiple times that the accepted length of the GET parameter values could also be a browser issue. I use Chrome as the default browser and just tried the URL in Microsoft Edge. The effect is the same. Maybe we could try to exclude a problem on the browser side? Which browsers are you using @ksainc @Jan-Gerrit ?

[Jan-Gerrit]

@arno1979 I use Google Chrome as the default browser but I also tried it with mozilla and edge. Same problem with each browser.

I mean with apache2 the default setting is 8177 characters. I tried to increase it using LimitRequestLine 100000. However, it hasn't changed the problem.

In php-fpm my limit is set to 4000

The transfer from O365 definitely works. I tested the whole thing on another server that runs under nginx, where it worked without any problems

[arno1979]

So we are definately faced with an Apache problem, right?

[ksainc]

Good Morning,

@Jan-Gerrit thank you for confirming that this is working in Nginx.

@arno1979 yes, this seems to be a Apache issue, Apache seems to be removing the "code" value when it is forwarding the request to php-fpm.

@Jan-Gerrit and @arno1979 are you using any plugins like mod_security with your Apache installation? Otherwise there must be something in the .htaccess file that is causing this.

Sebastian

[Jan-Gerrit]

Here is the list of my modules in apache2

Loaded Modules: core_module (static) so_module (static) watchdog_module (static) http_module (static) log_config_module (static) logio_module (static) version_module (static) unixd_module (static) access_compat_module (shared) actions_module (shared) alias_module (shared) auth_basic_module (shared) authn_core_module (shared) authn_file_module (shared) authz_core_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) fcgid_module (shared) filter_module (shared) headers_module (shared) http2_module (shared) mime_module (shared) mpm_event_module (shared) negotiation_module (shared) proxy_module (shared) proxy_fcgi_module (shared) proxy_http_module (shared) proxy_wstunnel_module (shared) reqtimeout_module (shared) rewrite_module (shared) setenvif_module (shared) socache_shmcb_module (shared) ssl_module (shared) status_module (shared)

The .htaccess file located in the document root of the nextcloud ist attached. I couldn't find any abnormalities

htaccess.txt

[arno1979]

Here are the modules loaded with my apache server:

Loaded Modules: core_module (static) so_module (static) http_module (static) access_compat_module (shared) actions_module (shared) alias_module (shared) allowmethods_module (shared) auth_basic_module (shared) auth_digest_module (shared) authn_anon_module (shared) authn_core_module (shared) authn_dbd_module (shared) authn_dbm_module (shared) authn_file_module (shared) authn_socache_module (shared) authnz_fcgi_module (shared) authz_core_module (shared) authz_dbd_module (shared) authz_dbm_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_owner_module (shared) authz_user_module (shared) autoindex_module (shared) cache_module (shared) cache_disk_module (shared) cache_socache_module (shared) data_module (shared) dbd_module (shared) deflate_module (shared) dir_module (shared) dumpio_module (shared) echo_module (shared) env_module (shared) expires_module (shared) ext_filter_module (shared) filter_module (shared) headers_module (shared) include_module (shared) info_module (shared) log_config_module (shared) logio_module (shared) macro_module (shared) mime_magic_module (shared) mime_module (shared) negotiation_module (shared) remoteip_module (shared) reqtimeout_module (shared) request_module (shared) rewrite_module (shared) setenvif_module (shared) slotmem_plain_module (shared) slotmem_shm_module (shared) socache_dbm_module (shared) socache_memcache_module (shared) socache_redis_module (shared) socache_shmcb_module (shared) status_module (shared) substitute_module (shared) suexec_module (shared) unique_id_module (shared) unixd_module (shared) userdir_module (shared) version_module (shared) vhost_alias_module (shared) watchdog_module (shared) brotli_module (shared) dav_module (shared) dav_fs_module (shared) dav_lock_module (shared) lua_module (shared) mpm_event_module (shared) proxy_module (shared) lbmethod_bybusyness_module (shared) lbmethod_byrequests_module (shared) lbmethod_bytraffic_module (shared) lbmethod_heartbeat_module (shared) proxy_ajp_module (shared) proxy_balancer_module (shared) proxy_connect_module (shared) proxy_express_module (shared) proxy_fcgi_module (shared) proxy_fdpass_module (shared) proxy_ftp_module (shared) proxy_http_module (shared) proxy_hcheck_module (shared) proxy_scgi_module (shared) proxy_uwsgi_module (shared) proxy_wstunnel_module (shared) xml2enc_module (shared) proxy_html_module (shared) ssl_module (shared) systemd_module (shared) cgid_module (shared) perl_module (shared) http2_module (shared) proxy_http2_module (shared)

The .htaccess file comes shipped with nextcloud as far as I know: htaccess.txt

For completion's sake this is what my apache virtual host file for nextcloud looks like [slightly cleaned up for privacy reasons], the non-standard directives are recommendations taken from the nextcloud documentation:

###Nextcloud###
<VirtualHost *:80>
  ServerName nextcloud.fqdn.tld
  ServerAlias www.nextcloud.fqdn.tld
  <FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/php-fpm.sock|fcgi://localhost"
  </FilesMatch>
  RedirectMatch permanent ^/(.*) https://nextcloud.fqdn.tld/$1
</VirtualHost>

<VirtualHost *:443>
  ServerName nextcloud.fqdn.tld
  CustomLog /var/log/httpd/nextcloud.fqdn.tld-access.log combined
  ErrorLog /var/log/httpd/nextcloud.fqdn.tld-error.log
  Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
  Header always set Referrer-Policy "no-referrer"
  SSLEngine on
  SSLCertificateFile /etc/httpd/certs/fqdn.tld/fqdn.tld.pem
  SSLCertificateKeyFile /etc/httpd/certs/fqdn.tld/fqdn.tld.key.pem
  SSLCertificateChainFile /etc/httpd/certs/fqdn.tld/fullchain.pem
  SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
  SSLHonorCipherOrder On
  SSLCipherSuite HIGH:!aNULL:!MD5:!3DES
  DocumentRoot "/var/www/htdocs/nextcloud.fqdn.tld"
  <FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/php-fpm.sock|fcgi://localhost"
  </FilesMatch>
</VirtualHost>

<VirtualHost *:443>
  ServerName www.nextcloud.fqdn.tld
  <FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/php-fpm.sock|fcgi://localhost"
  </FilesMatch>
  RedirectMatch permanent ^/(.*) https://nextcloud.fqdn.tld/$1
</VirtualHost>

[ksainc]

Morning @arno1979 and @Jan-Gerrit

Okay, those look like pretty standard configurations. I'm going to install Apache on my test system and see if I can replicate and solve this issue.

Sebastian

[arno1979]

Okay, those look like pretty standard configurations. I'm going to install Apache on my test system and see if I can replicate and solve this issue.

Hey @ksainc, I just wanted to ask if you made any progress yet or if I can help in any way?

[surendranr]

Hey @ksainc I am also facing the same error...

Error SS:

Log:

[arno1979]

I am also still waiting for progress on this problem. I also noticed that the app is not compatible with the latest Nextcloud 29 release and cannot be activated anymore. That will have to be taken care of as well.

[surendranr]

@arno1979 My version is NC 28, but it's still not working!

[arno1979]

Yes, we know. If you read up on the problem in this issue you will see that it the problem only occurs if you are running Nextcloud (no matter which version) on Apache. The developer built the plugin on a system running Nginx as webserver and the problem does not occur there.