Encryption: When a file cannot be decrypted, the GET returns an error 503 which aborts the sync

[ogoffart]

How to reproduce:

• Enable the encryption app
• Configure the client with oauth (which means encryption app will be broken, which is another issue Does not work with user-key encryption oauth2#105)
• The server reply an 503 to the GET when it can't decrypt the file
• The sync stops there.

503 is the error code when the server is in maintainence, and therefore the client stops syncing.

Ideally the server should return another error code.

[PVince81]

Would a 403 do ?

503 has been used by design for a while but I understand that it is not the appropriate code.

@sharidas

[ogoffart]

yes 403 will work as far as the client is concerned.

[sharidas]

While trying to reproduce the problem in the issue, I am hit with another problem owncloud/oauth2#104

I am using desktop client built using make from 2.4.0 tag of git. @SamuAlfageme helped me narrow down the issue to the fact that I had to modify the access rules ( .htaccess file ). Basically the .htaccess section for mod_rewrite which I gave a try was with the following:

• Replaced the mod_rewrite section of .htaccess with the one shared:

<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$
  RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$
  RewriteCond %{REQUEST_FILENAME} !/remote.php
  RewriteCond %{REQUEST_FILENAME} !/public.php
  RewriteCond %{REQUEST_FILENAME} !/cron.php
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php
  RewriteCond %{REQUEST_FILENAME} !/status.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php
  RewriteCond %{REQUEST_FILENAME} !/updater/
  RewriteCond %{REQUEST_FILENAME} !/ocs-provider/
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

This did not worked.

• Another approach I found ( by searching in google ), was adding line below to .htaccess

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

This did not helped

• Tried adding lines below to the default .htaccess

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

This did not worked.

[sharidas]

With the addition of line:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

in the virtual host conf helped the authorization redirected to clients sync page.
So this is the virtual host conf I used:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
Alias /testing "/home/sujith/test/owncloud/"
# for Shibboleth access
#Alias /oc-shib "/home/sujith/test/owncloud/"

<VirtualHost *:80>
<Directory /home/sujith/test/owncloud/>
  Options +FollowSymlinks
  AllowOverride All
  Satisfy Any

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

 SetEnv /home/sujith/test/owncloud
 SetEnv HTTP_HOME /home/sujith/test/owncloud

</Directory>
# The change made for vim + DBGPavim
# php_value xdebug.remote_port 9009
# php_value xdebug.remote_autostart 1
</VirtualHost>

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

fixed in PR #30059

[SamuAlfageme]

Just saw the fix in the working:

curl -i \
    -H 'Authorization:Bearer z15EpBd37NWiokxgXISYCVhwg9TLEIHtpyHMddIdNgeCMyY8gTBaxFnD9XNKvAL2' \
    'https://localhost/remote.php/dav/files/admin/mr-nobody-english.srt'
HTTP/1.1 403 Forbidden
[...]

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
  <s:message>Encryption not ready: Private Key missing for user: please try to log-out and log-in again</s:message>
</d:error>

... and from the sync client:

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.