I had noticed the “trusted_domains” configuration parameter; I had also noticed that it was apparently linked to failed attempts from a different location (different of my usual personal computer). But I did not understand it well.

As a matter of fact, a very clearly written post from Lukas Reschke, A tale about trusted_domains has been the source of my enlightenment.

The default installation of ownCloud had easily allowed me identify that www.mydomain.com in the list of trusted domains (of domains used to publish the cloud information). I thought that my difficulty was coming from trying out of mydomain.com (as if I was on the server), but my trusted_domains list needed to simultaneously contain www.mydomain.com and mydomain.com.

This was rather silly, but I did not think more about it: I was not typing the same address depending on where I was connecting (by luck, or rather lack of luck) and I started to believe that the location was important (and it was not really).

So, I replaced

'trusted_domains' =>
array (
0 => 'www.mydomain.com',
),

with

'trusted_domains' =>
array (
0 => 'www.mydomain.com',
1 => 'mydomain.com',
),

Done!

The advantage of using this connection parameter was to avoid a security risk (well explained in the above post) and to allow different addresses to be used to access the same cloud server. For example, when users on the internal company network are using a different address (access through internalcloud.local) than those outside (access through mydomain.com). In this case, we would use configuration parameters like:

'trusted_domains' =>
array (
0 => 'www.mydomain.com',
1 => 'mydomain.com',
2 => 'internalcloud.local',
),

Good! One problem solved.

After that, it’s clear that ownCloud is a very good product to replace DropBox with a tool more personalized and more secure (at least, it is not hosted in an unknown place like DropBox).