Access control to DT server is insecure

We have problems with DT server.
The server provides the possibility to define users/rights and thus control the access to the database. Unfortunately, it does not work reliably. Users with Chrome on macOS and Vivaldi on Linux get direct access to the database. They do not need to log in to the database. We can reproduce this behavior on different systems. Also on systems where the web server has not been called yet, so where no login data can be present either. How can we prevent this?
When a user tries to sort the search results returned by the database server, it does not work. This would not be a big problem. Unfortunately, the browser does not load any more search results afterwards. The button “Load more search results” becomes ineffective.
With kind regards
Wolfgang Groß

Translated with (free version)

  • Have you saved the credentials in the browser?
  • Are those credentials syncing between machines ?

If you try a Chrome Incognito session you will see that it always prompts you for credentials

This confirms that the behavior you describe is due to cookies or some other method of storing credentials specific to a User Account and does not allow access by outside parties through the web.


May be that you can produce such behavior with Chrome. Nevertheless:
What happened?
Previously, users had access to the database as guests.There were no user accounts in the database. To get access, they had to log in via VPN to the router where the DB server is located in the network. They could contact the server via http and log in as a guest.
We have changed this procedure. We put the DB server in a DMZ and enabled database access via https, so the user can access the database without VPN. Each user got his own “account” in the DB server. We have completely disabled the rights of the guest account. Actually, we would have expected that in this case for the former guest users the login dialog would appear and ask for the user data.
Unfortunately, this is definitely not the case. The same users who had previously connected to the server as guests were connected to the database without further ado. They did not even have a chance to enter the access data currently sent to them. They could not have been present on the system at all. We were able to verify this behavior in a test account: Again, we were able to connect to the web server without entering any credentials, just on the basis that the computer had previously connected to the database as a guest.

Translated with (free version)

The same problem on Windows machines. Former guest users can log in although the rights of “guest” are disabled. You do not need to use any credentials for this. For control all browser data are deleted on one of the machines. No difference.

A screenshot of the server’s settings would be useful. And how exactly do they log in? E.g. via the form or HTTP? Which account do they use?

The server is accessible via a web address (DynDNS). An Apache2 reverse proxy is connected in front of the DT server, which connects via localhost to the DT server via htttp. Apache2 can be reached via https.
In this configuration the DT server does not respond with the login page. The users get direct access to the databases on the server; even if they were previously connected to it only as a guest. This, although the guest account has no rights. Also the logout function does not return the login page.
Note: if you implement authentication through Apache2 (Authtype Basic), the DT server reliably returns the login page again.
Tested with Chrome, Firefox, Safari and Vivaldi under Win10, MacOS, Ubuntu 20/4 and Debian 10.

But direct access to DEVONthink’s server does work as expected?

How exactly did you implement this? Does the proxy use any caching? A simple redirect of the requests shouldn’t cause such issues.

A simple redirect of the requests shouldn’t cause such issues.


How exactly did you implement this? Does the proxy use any caching?


SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/…/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/…/privkey.pem
ProxyPreserveHost On
ProxyPass /
ProxyPassReverse /

Is this the complete config?

Listen 443
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!ARIA:!CAMELLIA:!AES128:!AES256-SHA:!AES256-SHA256:!AES256-GCM-SHA384:!AES256-CCM8:!AES256-

SSLHonorCipherOrder on

SSLProtocol -ALL +TLSv1.2
SSLPassPhraseDialog builtin

SSLSessionCache “shmcb:/private/var/run/ssl_scache(512000)”
SSLSessionCacheTimeout 300

DocumentRoot "/Library/WebServer/Documents" ServerName ServerAdmin ErrorLog "/private/var/log/apache2/error_log" TransferLog "/private/var/log/apache2/access_log"


AuthType Basic

AuthName “Geschuetzter Bereich - Bitte geben Sie ein Passwort ein!”

AuthUserFile /private/etc/apache2/htpasswd

Require valid-user


SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/…/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/…/privkey.pem
ProxyPreserveHost On
ProxyPass /
ProxyPassReverse /

<FilesMatch “.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars

<Directory “/Library/WebServer/CGI-Executables”>
SSLOptions +StdEnvVars

BrowserMatch “MSIE [2-5]”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0

CustomLog “/private/var/log/apache2/ssl_request_log”
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x “%r” %b”


The bold instructions are in the comment.

Thanks! But direct access to DEVONthink’s server does work as expected?

We cannot say that.
At least not for the direct connection via https with DT Server and for the use of user accounts. We didn’t try that because we had problems with DT Server using certificates. We were able to easily resolve these issues through Apache, including automating the renewal of certificates, etc.
We have no insight into how DT Server handles authentication. We can only assume that the problems we are facing stem from the fact that there are vulnerabilities in the process.
We are confident that we can solve the problem by using Apache.
Thanks again for your efforts to help us solve the problems.
Good night!

If I understand your setup correctly, you’re connecting the reverse proxy to DT server via HTTP. In that case, you could try to use wireshark to get a protocol of the exchange between Apache and DT server.

The server log (see Preferences > Server) plus the exact time (!) when people tried to use the guest account but shouldn’t be allowed to would be useful. Just send the log to cgrunenberg - at -, thanks.

I can’t provide the data currently, because for that we would have to change the configuration of the access to the server. For this we would have to disconnect the users from the server. I do not want to do that at the moment. We have just provided the users with new instructions on how to log in and we don’t want to create any irritation.
If the data is important to you, I would do that at a better time.
For us, the problem is solved using Apache for access control.
If other users of the server who handle encryption through the DT server have not reported such problems before, it could be that this is an individual problem that arose due to the interposition of Apache to manage https/certificates. We suspect that this is due to a vulnerability in the DT server. That may not matter in a normal configuration.

The log (see file ~/Library/Logs/DevonThink 3 WebServer.log) would be indeed useful.

I could send you the file and tell you the eventual date we switched the login to Apache. Would that be enough for now?

Hard to tell whether it’s going to be enough but it would be definitely useful, thanks!